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ABSTRACT 


The INTEL 432/670 microcomputer system contains the 
LAPX=-432 microprocessor which executes compiled ADA 
proqrams., The compiler resides on a host VAX 11/780, and 
compiled proaqrams are downloaded to an INTEL MDS 809 system 
where they are transferred to the 432/670 for execution, 
This thesis deseribes a preliminary performance evaluation 
of the INTEL 432/670 through the use of selected benchmark 
algorithms from the Comouter Family Architecture (CFA) 
study. A descriotion of the Nardware components of hoth the 
MDS @00 and 432/670 is orovided, ineludinag the modifications 
made to the operating system to allow compatinility with 
existing hardware, Additionally, the heneAmark program 


source code and aiuser’s manual are apcended, 
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I, INTRODUCTION 


A. THESIS DESCRIPTION 

The development of new engineering tools is accompanied 
by the perceived need to find applications for those tools, 
Microprocessors are no exception, When a new computer is 
introduced it is important to Know what, if any, sianificant 
benefits can be realized through its use, Thinas to consider 
in evaluatina a microorocessor include several quantitative 
items, such as, tinstruction execution speed, memory 
capacity, and overall performance, Less tangible, but 
equally imoortant qualities of multiprocessor support, user 
erorection, and ease o£ programming alSo need to be 
meastired, The introduction of the INTEL {APX=-432 in 1981 
represented a radical cnanae from traditional computer 
architectures. Previous advances in inteqrated circuits 
have Primarily focused on larger memorv, and faster 
execution. The LAPX-432 has addressed these issues, but has 
also tackled manv of the problems found in software 
enaineering. 

This thesis involved the setup and evaluation of a 
modified INTEL 432/679 cross development system to measure 
the overall nerformance of the programming langquage ADA 


executing on a eomoanion vehicle, the INTEL {LA°X=432 





microprocessor, The motivation for this investigation was 
straightforward, Since the Department of Defense has spent 
considerable time and effort in developing the ADA language 
4t would be interesting to observe how the language performs 
on a processor that was designed with identical goals. It {is 
not often that a language ard processor are developed in 
Parallel. More importantly, the INTEL {APX=432%s unique 
architecture directly supports many of the important ADA 


lanaquaqe features. Such as: 


1. Access protection for packages, 
2. Automatic maintenance of activation record stacks, 


a, Mumteapmocessor “support for multitasking, 


This support may provide for less expensive, easier to 
maintain software, a common objective of both Nardware and 


software desfaners, 


Be. EVALUATION OF COMPUTER ARCHITECTURES 

Evaluation of computer architectures and computer 
languages has traditionally been an investigative process 
@urected toward a soecific apolication. This study involved 
the qeneral purvnose applicability of the lanauage and the 
processor, The choice of measurement metnods used followed 
an earlier ertort performed by the Computer Family 
Architecture committee in 1976 concerning general purvnose 


computer application evaluations. In particular, some of the 





benchmark programs used by the committee were coded in ADA 
and then executed and timed on the LAPx-432, Although no 
provisions have been made to eliminate the effects of 
compiler efficiency, or inefficiency, the results should 
give an indication of the execution speed available to the 
end user. This method of testing was chosen since the 
processor is designed to be programmed {tn a hiagn level 
lanacuage (ADA). No assembler is under develooment or planned 
for by tne manufacturer, Therefore, if the language = and 
processor are to be used as designed, then the performance 
needs to be evaluated in a working environment, That is, 
proaqrammers procramming in ADA and compiled code executing 


on the orocessor, 


Ce. THESIS ORGANIZATION 

ines tiyé@sis 25 compoéed of six chapt@®rs and five 
appendices, Chapter II is a brief discussion of the work 
done by the Computer Family Architecture committee (CFA) and 
it®s applicability to this investigation. Chapter III is an 
Introduction to some of the uniaue architectural aspects of 
the LAPX-432 and Row these new featuras support the language 
ADA, The benchmark Program deseriptions and timing results 
mee in Chapter IV. Ineluded in that chapter is a description 
of the carameters passed and the calling conventions used, 
An attempt has been made to aive an impartial evaluation of 


the CPS 432/670 svstem in Chapter V, Finally, in Chapter VI 


19 





the reader will f1iNd what baste conclusions have been drawn 
about the LAPX#432 and the CDS 432/670 system as a result of 
this study. The aopendices are filled with the material 
necessary to repeat any of the results obtained in Chapter 
IV. They include a description of the hardware and operating 
system modifications performed and a listing of all the ADA 
source code. As a convenient reference the algorithms used 
py tne CFA are provided in Appendix D, A users manual is 
included in Apopend{x F to allow a new user to quickly become 


familiar with the svstem, 
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Pi, THEM EARY COMPUTER PANT LY ARCHITECTURE 


The Military Computer Famlly architecture (MCF) refers 
to the architecture standard defined in a Study done by the 
Computer Family Architecture committee (CFA) between October 
of 1975 and August of 1976, The initial study coneluded that 
the POr-ii best met the criterfa for a military computer 
family standard, Since that time another CFA related study 
by Dietz{1]) suggested several improvements in the algorithms 
used to evaluate architectures. An overview of the CFA 


project follows, 


ame. GEA/MCE PROJECT MOTIVATION 

The CFA/MCF voroject was a joint ARMY/NAVY effort to 
develop a method of comparing computer architectures for use 
on a@ general class of applications. The enormous sums of 
money that the Department of Defens@ was spending on data 
processing Prompted the investication into the possibility 
of defining a standard computer architecture.Decreasing the 
life eyele costs of computer svstems played a major role in 


the committees selection criteria, 


Be CFA/MNCF PROJECT DESCRIPTION 
One of tne first items the CFA examined was the reason 


for skyrocketing data orocessing costs, The answers they 
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obtained were not too surprising. That is, computer 
selections often aeenibas ed On local schedules, funding, and 
profit considerations with little regard for the impact 
these decisions have on long term hardware/software 
logistics costs, Consequently, {ncompatible military systems 
are contrisuting to the oroblems of development and 
maintenance of software, Although a formal movement = in 
standardizing a lanaquage was underway (ADA), there was no 
method for standardizing an arehitecture, It was with this 
mandate that the CFA. committee pursued the evaluation of 
several available computer architectures, with the goal of 
selecting a standard. 

A standard arehitecture does not mean specific numbers 
eee regqisters, accumulators etc., Sut rather the structure of 
the machine that a proarammer needs to Know to write nis 
proarams, For example, if the architecture standard reauires 
stack relative addressing, then any machine having that 
Mestruction Cand the other required instructions!) can be 
proarammed by a given programmer without nis having anv 
Knowledge of how the tnstruetion is implemented, The 
proarammer Knows there’s a stack and ae stack relative 
address instruction? the hardware implementation is 
transparent to Rim. In this fasnton, any two computers 
having the standard arehitecture can run the same software, 


The advantage realized is that new hpardware with faster, 
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more efffeient pnysical eharacteristics, can run the same 


software with little or no mod{fication. 


Cy CFA SELECTION CRITERIA 

The CFA committee initiated the selection process by 
specifying nine absolute qualitative criteria and Several 
quantitative criteria that they felt an architecture must 
satisfy to meet the needs of a military computer renew, 

1. tative Crireria 


The nine qualitative eriteria were: 


1. Virtual Memory 3: The arenitecture must Support a 
virtual address to physical address translation 
mechanism, 


2. Protection =: The capability must exist to add new 
exoerimental croorams without endangering the 
Liable operation of existing Orograms., Arenitece 
tures with orivileqed: modes of operation 
qeneraliv meet this eriteria, 


ae clae.ing Point Orerations : The explicit supoort 
ef floating point data types with more than 19 
Aweital dicgecs! OF S.4ganiticance, 


4. Interrupts and Traps : The capability to write a 
trao hAandler to respond to any trap condition 
wifh the program resuming operation of the proe 
aqram, Additionally, the arenitecture needs to 5e 
camable of resumina execution following any ine 
eBrrust. 


5S. Subsettabllitv : Some of the components of the 
architecture must be abl@ to be factored out of 
tive €nil arenitecture® 


6. Multiprocessing : Support of communication = and 
synchronization of multiple processors, 


7. I/0 Controllability : A processor must have the 


ablliitv to exereise absolute control over any I/O 
processor, 
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8, Extensibility : Some method needs to exist to add 
new instructions to the architecture consistent 
with existing formats. 
9. Read Only Code : It must be possible to execute 
programs from read only memory, 
These nine criteria were definitely subjective in nature but 
did provide a aqood {tinitial screening for any standard 
architecture candidate, Although fhe study was done hefore 
ee introduction of the INTEL 1APX<-432, most of the eriterta 
are met or exceeded by the LAPX-432 with the exception of 
the interrupt capability. The fLAPX-432 -has no hardware 
interrupt, however, it is designed to overate with an 
attached processor which does nave an interrupt capability. 
2. Quantitarive Criteria 


The quantitative criteria judaed by the CFA 


committee included the following items ;: 


1. Virtual address space, 
2. Physical address space, 
3. Fraction of address svoace unassiqned, 


4. Size of the central processor state (amount of 
CPU information stored on interrupts), 


5. Usage hase (number of units tin operation), 


§. I/O initiation (efficiency of peripheral device 
accessibility). 


7. VirtualizabLlityv (support of virtual machines). 


8. Direct instruction addressapllity,. 
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9. Maximum interrupt latency (time from receipt of 
interrupt to processing), 
D. MEASUREMENT PARAMETERS 

The avantitative criteria were evaluated, in part, by 
the use of twelve benchmark programs, These programs were 
nand assembled by several different programmers, and then 
statistically analyzed for program use of computer soace and 
time. The measurement parameters uSed were; 

S: Measure of soace, the number of oytes used to 

represent a test program, 

Ms Measure of execution time, the number of bytes 

transferred between primary memory and the processor 

durina execution of the test program, 

R: The number of bytes transferred among internal 

registers of the processor during execution of the 

test preoran, 

Although the S§,M, and R measures are useful in 
evaluating conventional architectures, they are not readily 
applied to the INTEL LAPX=-432, In fact, the microprocessor’s 
meemuescturer has stated that there is no intention of 
supplying an assembler, nor is one under development. This 
would make the measurement of S and M diétéficult and tne 
measurement of R virtually impossible, For this reason, the 
eValuation of the INTEL 1APX-432 was primarily based on the 


execution timing of selected henchmark programs, 
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E. BENCHMARK EVALUATION DESCRIPTION 

The original CFA committee developed twelve benchmark 
proarams to evaluate the selected criteria, <A obprief 
description of the programs follows with a complete 


algorithmmic deseription in Appendix D, 


1. T/0 kernel, four priority level interrupts, 
2e I/0 kernel, FIFO processing. 

3. I/0 device nandler, 

4, Large fast Fourfer transform of a large vector, 
5. Character searcn. 

6, Bit test: set, or reset, 

7. Runge-Kutta integration. 

8. Linked list insertion. 

ee GQUICKEOrC, 

HOLeaocii to floating point conversion, 

ii. Boolean matrix transpose, 


12. Virtual memory space exchange, 


These programs tested many of the items considered to be of 
value by the CFA committee, however, a later study by Dietz 
C1) determined that the number and types of test oroqrams 
should be expanded, The oroposed set of benchmark orograms 
consisted of sixteen programs organized into four groups as 


follows: 
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A, Interrupts and traps, 


1. 
2 
de 


4. 


Terminal input driver, 
Message buffering and transmission, 
Multiple priority interrupt handler, 


Virtual memory exchange. 


B, Miscellaneous, 


De 
De 
Te 


8. 


Sea ke*veetor disclay. 
Array maniounlation=LU decompoosition, 
Taroet trackins. 


Digital communications processing. 


C., Address manipulation, 


Je 
10, 
il. 


ee 


Hash table search. 
Linked list insertion. 
Presort, 


Autocorrelate, 


D. Character and bit manipulation. 


he 
i4, 
or 


16. 


Character searcn. 
Boolean matrix transvose, 
Record unpackina. 


Vector to scan line conversion, 


A comerlete alaorithmic description of these 


eproaqrams can also be found in Appendix D, 


benchmark 


These sixteen algorithms were thought to more rigorously 


test specific 


standard, 


features of the computer family arenitecture 


None of the above benchmark programs are 
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necessarily firm algorithms that must be adhered to, 
However, they do provide some guidance in the type of tasks 
that must be performed by a computer in order for it to 
fulfill the minimum requirements of an architectural 
standard, In the original evaluation the PDP=-11 was 
selected as the best candidate architecture. for the military 
computer family, Since that time several majer advances in 
beth Nmardware and software mave occurred, The unique 
architecture of the INTEL LAPX-432 provides a different test 
platform for the execution of the benchmark Drograms, Those 
proqrams which were supported by the current INTEL ADA#=432 
compiler were coded, executed, and timed, The results are 


Summarized in Charter IV of this thesis. 


es 





TII. THE INTEL LAPX-432 MICROPROCESSOR 


Ae ARCHITECTURE DESCRIPTION 

Computer architectures in the majority of commercial 
systems available today can be viewed as refined descendants 
of the often termed Von Neumann comvuter architecture. A 
Von Neumann computer arenitecture usually includes the 


following properties (2): 


1. A single, sequentially addressed memory which 
contains both orogram and data, 


2e No explicit distinctions between instructions and 
data, Rather, instructions and data are diss 
tinauisned by the operations directed towards 
them, 


In 1981, Intel announced a 32ebit VLSI microprocessor 
incorporating several architectural innovations [3]. This 


announcement stated: 


"The Intel LAPX 432 represents a dramatic advance in 
comewoer  arenitecturé: it is the first computer 
whose architecture supports true software trane 
sPparent, multiprocessor operation: it is the first 
commercial system to support an object-oriented 
programming metnodoloay; it is desiacned to be 
programmed entirely in nAiqhelevel languages; it 
supports a virtual address svdace in excess of 
amcriliion bytes: and it supports on the chio itself 
the proposed IEFEestandard for floatina point arith= 
metic," 
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The next few pages will be devoted to oroviding a oprief 
overview of the following arenitectural aspects of the 


LAPX=4323 


1. ObjecteOrientation, 
2. Transparent Multiprocessina, 
3. Capablilty=Based Protection. 


4, Operating System Suopert. 


1, ObijecreOrtentation 

What does it mean to be an objectebaséd computer? 
Unlike the classical Von Neumann architecture described in 
the introduction, memory is not accessed a8 a single, 
contiaquous block. Rather, the memory {is considered as a 
collection or set of smaller units called objects, each of 
which occupies some contiguous amount of memory. Very 
important and fundamental to this conceot is the object’s 
meeognition. This can occur in software, or as in the 
majority of cases for the 432, in hardware, This recognition 
enables the object to be typed or classified as to the 
operators which are allowed to act upon the particular 
object, Since the 432 arenitecture can determine the 
Classification of an object {Lt can prevent incidents such as 
instructions (e.g. instruction objects) being interoreted as 
data, and conversely, data (e.g. data objects) being 


executed as instructions. 
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At the machine level, objects can be theught of as 
being segments, a segment being a Set of contiguous memory 
locations whieh in the 432 case can range from 1 to 65,536 
bytes in length, However, there can be some differences in 
the 432 case. Specifically, an object can be any one of the 


follovwins: 


1. A Single segment. 
2e A collection of segments. 


3, A cart of a segqment. 


This latitude in object abstraction gives compiler designers 
€@ powerful base on which to build object oriented compilers 
(ADA). 

inceiehneas moved tire recognition of, specific ohject 
types biplaete. the 432 hardware, as alluded to above, 
Additionally, certain overators on these objects are 
incorporated directly into Nardware, while other operations 
must be done via software, The net effect of this decision 


is twofold: 


1. Increased relflabillityv of all operations, 


2e Increased eaxecution speed of certain functions, 


Figure 1 {illustrates some typical iAPX=#=432 hardware 


recognized objects: 
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Figure 1, Hardware Recoanized Objects 


The incorporation of an object-based programming 
methodology, in the manufacture’s own words, ",.,raises the 
level of the hardware/software interface", The justification 
for this statement can be found in the followina example, 

Early computers had verv simple hardware operations, 
These early machines were not capable of supporting 
floating=point manipulations directly. Te You wanted 


floatina=scoint operations you had to implement them in 
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software, With the passage of time and increased 
Peehnetogteat progress, computer hardware gained 
functionality. What were once software functions found 
themselves migrated into hardware, a classic example being 
floating point operations, This evolution of software into 
hardware is generally regarded as raising the level of the 
hardware/software interface in a computer architecture, The 
432 carries this progression one step further by placing 
system management operations, such as orocess scheduling, 
memory management, and interprocess communication into the 
hardware also, Referring back to Figure 1, the imoortance of 
such objects as processor object, process object, etc. 
should now take on greater sianificance, Naturally, more 
than these basic system objects will he needed to implement 
the operations listed above, The processor must be able to 
manipulate these objects in an appropriate way so that what 
is traditionally done in a series of proaram steos is now 
accomplished with a single instruction. The net effect of 
such hardware instructions {is to inerease processing sneeds, 

Recalling the example of fleatina point operations, 
we find that their incorvoration into hnardware increased 
their spveed of operation. Furthermore, speed and reliability 
are sioanificantly enhanced when an operation is imelemented 
in hardware, However, the cadability based architecture adds 
@ sianificant amount of execution time to each instruction 


and consequently the performance of a orocessor is reduced, 
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The choice of an object=based computer arenitecture, 
besides raising the nardware/software dnceresee? integrates 
ideas that have developed over the last decade in software 
engineering, These inelude data abstraction, domain based 
protection, information hiding, and high-level system 
functionality, The iL1APX 432 48 an attempt to bring these 
notions conerently together in a single architecture, 

Summarizing, an object can be reacarded as possessing 
the following provcerties: 

1, A data structure that contains information in an 
organized manner. 

2. A set of basic operations may manipulate an obs 
ject, The 432 Nardware ensures that these are the 
only operations that can manipulate the data 
Sc rict ur &’ 

3. An object can be addressed as a single entity. 

4. An obdect has a label whnicn specifies the 
object’s type (e.9. processor vs. process), 

Lastly, as regards the relationship between segments 
and objects, a& seament refers to the physical structure of 
data in memory, i.e. where the structure is located. An 
object refers to the logical structure of data in memory, 
i.e. how the memory is used, 

2. Transparent Multiprocessing 

One of the most highly opromoted features of the 
LAPX=432 is its software transparent multiprocessing 


capabilities, also called "“fineremental computing cower", 
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what this means is that the number of physical processors 
(GDP boards) in the 432/670 system can be changed without 
any corresponding changes in application software, That is, 
a user’s application program never has to be concerned with 
the nmumber of physical processors present, The only visible 
effect of havina more than one physical orocessor is the 
increase in system throughput. This kind of flexible 
performance is not uSually associated with microcomputers, 
As applications become more complex and more dynamic, it 
becomes increasingly difficult to predict how much 
processing power a system will need to meet its performance 
goals. This uncertainty can be a serious source of risk, An 
application may have to commit itself to a processor some 
time before any code has actually been written. This problem 
is solved by the {APX"-432 through the use of processor 
objects, Processor objects are abstractions of physical 
processors and hence their behavior can be manipulated like 
any other object, 

Transparent multiprocessing is accomplished through 
me use of the processor object. Riieemeex is cence ofA 
particular physical processor is immaterial. system 
throuqhput can be tinereased by adding onysical processors 
(GDP boards) and therefore creating more processor objects. 
More processor objects means that more user processes can 
execute, Similarly, the removal of a opnysical ovorocessor 


results in the removal of a processor object and 4a 
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subseguent reduction in the total performance, Fault 
tolerance can thus be said to be improved by the fact that 
in a multiple processor environment, if a processor fails, 
it 48 simply removed from the system. The only effect should 
be some reduction in throughput. In order to describe how 
this "software transoarent" multiprocessing is achieved, 
other 432 objects besides processor objects and oprocess 
objects, will be introduced, Process objects can be equated 
with user programs in the discussion which follows, 

The term disvatching refers to the assignment of a 
432 Processor to some process which is waitina to execute, 
In the 432 case, this is the opaliring-up of a processor 
object with a process object, The manner in which this ts 
done is throuagn the aid of another particular type of object 
called a dispatecning port object. Since this is an object, 
it also has certain uniaue ovnerators which apply to it, The 
dispatching vort object can he thougnt of as a queue-like 
Gece structure’ which can contain process objects or 
processor objects, but never both, Processors, and hence 
tneir processor objects, are self dispatching on the 432. 
Therefore, when a orocessor completes its current task or 
process it examines the dispatching port object to determine 
{f there is a waiting process, represented by a process 
object, enqueued at the disoatehing port. If there is a 
Process object oresent, the process object {is "bound" to the 


oOrocessor object, that is, a link is formed between the 
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processor object and process object. The processor then 
dequeues the process object from the dispatching oort, and 
then ovroceeds to execute the process. Conversely, if there 
are no processes (process objects) enqueued at the 
dispatching port, the precessor enqueues its processor 
object at the dispatching port, in effect waiting for the 
next ready process, Processes are not dependent on 
sdecifically which processor is executing it, or how many 
processors are present in the svStem. Processes ready for 
execution are simply enqueued at the dispatching port, The 
presence of more physical processors simply ‘Neans that the 
average time a process is queued up at a dispatching port 
should be decreased, 
o. Capability Based Protection 

Sharing data among a computer system’s users in a 
carefully controlled way nas been a subject for much 
investiaation in computer systems. Implementation techniaues 
aimed at providing for this controlled information flow have 
run from introducing privileged and user instructions (4.95. 
IBM 360/370) to ALerarenlcal protection systems as 
Sraesicaily iliustratéed in the MULTICS rina ‘Structure. 
Intel’s approach to this ocroblem in the 432 architecture has 
been to implement what are termed capabilities, 

Cacabilities can be thought of as tickets, the 
possession of whieh conveys orivileaes, normally the 


Drivileae to access a segment, In the 432 case, to tnink of 
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them as a pointer plus access rights oair would be an even 
closer analogy, Possession of a capability means that access 
to a seaqment is allowed under the access riqnhts associated 
with that capability. Access rights are: read, write, both, 
or neither. In order to ensure protection, certain processes 
should not be permitted to possess capabilities which oarant 
nonediseriminate access to certain vortions of memory. For 
example, user processes should not nave access to the memory 
where the operating system is contained, Therefore, because 
of their function and {inherent potential fo be used 
maliciously, capabilities must be unforgeable. In the LAPXe 
432, capabilities are recognized and overated on by hardware 
to assure this needed orotection, The set of capabilities 
accessible to a process at any one time is called the domain 
of protection. As a process runs, the domain of protection 
will change. The ideal to be realized is that the domain of 
protection should always be exactly matched to the 
requirements of the process; that is, it snould contain 
capabllities for all the segments that the process needs to 
access and nothing more, This satisfies the principle of 
“minimum oprivilece’ in secure systems jaraon, 

The original reasons that led to the desire to 
design a computer with a capabllity based architecture may 
be summarized under ruggedness and security, Ruggedness 2n 
this sense means the ability of the system to survive the 


consequences of nardware failures or software bugs (4). 
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Security, on the other hand, can be thought of as ensuring 
that access to memory is determined exclusively by the 
access riahts of the particular process in question, 

There are basically ‘two distinct ways Of 
implementing capabilities in hardware, These can be termed 
the tagged and partitioned approach [5]. In the former, all 
words in the system carrv a “’tag’ bit waich plays no part 
ether than to indicate whether the oarticular word is a 
eapability or not, In the partitioned approach, words carry 
no tag, so it is not oossible by examining a word in memory 
to determine whether it is a capabllity or data word, 
Instead, the tyoe of segment is important, 1l.e. there must 
be capabllity segments which contain capabilities and 
nothing more, and °data® segments which contain anything but 
capahilities, The LAPX 432 uses the partitioned anproach,. 

Intel’s decision to t{imolement the partitioned 
approach causes us to siiantiv refine the concept of an 
object as discussed earlier, As was previously stated, 
objects in their physical form are equated with segqment(s), 
A combination of an object-based architecture with 
capabilities imolemented in the partitioned apcroach means 
that each object is comnosed of two distinet parts, a data 
Part anda capability part. Indeed, in the 432 architecture 
there are two fundamental segment base types, These base 
types are called data seaments and access seqments. A data 


secment can contain anvthing exceot capabliities, whereas an 
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access seqment can contain only capabilities, Therefore, an 
object snould now be correetily envisioned as being comprised 
of these two segment types. An example of how this is 
actually implemented for some of the system objects is 


snown in Figure 2, 


processor object 


| Se wae aee aeeeae & @ @ ; 

| menmeewnnwencaaen | | mean awnewene | 
SO noose sanoseor | 
[onoonoccnoe ooo e | aai—re | 


orocessor access processor data 
seaqment segment 
(capabilities) 


eroc#ss obitact 


process access Process data 
seqment segment 


Fiqure 2, Object Representation 


Summarizing, Intel has implemented capability based 
support for memory protection in the 432, These capabilities 
can be thought of as an address of, or pointer to, an object 


with an attached tyvne describina the classification of the 
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referenced object (¢.q. process object, context object,etc,) 
and an attached protection mode (e.g. read only or 
read/write). In the 432, Intel has decided to call 
capabilities access descriptors hecause of their similarity 
in concept to pointer implementation in ADA which is termed 
an ’aecess’, Furthermore, objects in the 432 svstem are seen 
to be comprised of both data seaqment(sS) and capability 
C(aceess descrintor) segqment(s). The data seqment of an 
object couvid be thought of as containing information 
intrinsic to the particular type of ebject. The capability 
segment on tne other hand, contains capabilities for all the 
other obfects it may need to reference, Additionally, 
ceapablilities are seen to enforce the orinciple of minimum 
privilege, Perhans providing an Important tnsdent into 432 
performance, M,V, wilkes has said [6]: 

"Comoared with a conventional computer system, there 

will inevitably be acost to be met in providing a 

system in which the domains of protection are small 

and frequently changed. This cost will manifest it-= 

self in terms of additional hardware, decreased 

runetime speed, and increased memory occupancy, [It 

is at Dresent an oven question whether, boy the adon= 

tion of the capability approach, the cost can be 

reduced to reasonable propnortions," 

4. Qperating Svstem Support 

Like the 432 hardware, Intel has created an obdject= 

orfented operating system for the LAPX 432 called iMAX, It 


has been desflaned as a multiprocessor operating system, and 


consequently Ee accommodates any Number of running 
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processors. As a result, all synchronization within the 
system must be explicit. Furthermore, as the manufacturer 
has pointed out (7), the 432 and iMAX are products primarily 
intended to be used by original equipment manufacturers in 
the construction of their products. Related to this is the 
fact that {MAX does not provide a command language or a 
human interface, rather it is designed to provide executive 
services to usereprovided software which makes calls te 
iMAX, 

Many traditional operating system orimitives are 
implemented as hardware functions in the 432, In an effort 
to elaborate on the relationshio between tne LMAX ovderating 
system and the 1APX=-432 functions, a digression is in order, 
AS pointed out earlier, the LAPX 432 architecture provides a 
higher level of functionality in hNardware than conventional 
computers, Important system management functions are 
realized through hardwareerecognized representations, i.e. 
objects. High level operations on these system objects (see 
Fig, 1]), such as sending a message between processes, are 
provided as single machine instructions. These features of 
the 432 are referred to as the Silicon Ooerating system. 
These features are not in themselves an ovoeratinag system, 
but contribute areatly to the building of one, 

The relationship between LMAX and the hardware might 
best be described as cooperation, iMAX doesn’t simoly run on 


the nardware, rather the Nardware actsS autonomously to 
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provide important services, such aS processor self= 
disvatehing as pointed out earlier. A good examole of the 
divisien of labor which occurs between iMAX and the 432 
hardware can be found in storage management. Hardware 
defines system objects tsed for storage management, provides 
single instructions that allocate new objects, and sets flaq 
bits needed for storage reclamation and virtual storaqce 
management, iMAX will then provide services whieh will 
create and reclaim local storage pools and will orovide 
processes which compact storaqe and reclaim unreferenced 
objects. 

Probably the most notable point about iMAX is that 
the user may view IMAX as a set of ADA package 
specifications, each of whieh ecorresdonds to a particular 
service provided by the system, Additionally, there is no 
distinetion between iMAX packages and userewritten packages, 
IMAX operations and user operations are invoked in the same 
way. There is no special calling convention, no ‘’Supervisor 
Call’ instruction, as is the case in many current commercial 
systems. The effect of this particular implementation is 
B¥etol4: 

i. Users can create subsets of iIMAX by omitting 
unused packadqes, 


2.e Users can create supersets of iMAX by addina 
thetr own nackages, 
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iMAX also benefits from tne 432°s capability 
protection mechanism described earlier, References for 
system objects can be passed to user processes without fear 
of damage or system compromise because the rights associated 
with these user process capabilities nave been modified by 
iMAX appropriately (@.q0. read only), User processes cannot 
corrupt these references passed from iMAX, 

Like the 432 hardware, iMAX is in a continual state 
of change cy Intel, Version 1.0, wnich this thesis worked 
with, is a preliminary version intended to get potential 
users quickly acquainted with it in order to acquire the 
ability to execute ADA proarams on the 432, AS a result, the 
number of ADA packaaces whieh the user can tailor to his or 
her application are relatively few, As advertised, the 


following services are provided oy iMAX, V1.0: 


t. Configure and initialize a mnultipleeGDP systen, 
2e Read from and write to the debugaer console ONLY. 


3. Create and start multiple user srocesses definad 
at compile time, 


4, Communicate between user processes bv exchanging 
messages, 


S. Inspect type, rights, and storage information 
contained in access descriptors and object 
deseripotors, 


6. Insvect context and process dependent information 
in a running program’s environment, 
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Later versions are supposed to support Attached 
Processors which are essentially the means by whieh the 432 
can communicate with tne outside world, When this support is 
finally implemented, the current, severely Limited I/0 (i.e, 
debugger console only) will be replaced by a variety of 


conventional I/0 devices, 


A, ADA LANGUAGE SUPPORT 
AS was previously mentioned, there was a considerable 
amount of varallel development between tne ADA lanaquage and 
the INTEL LAPX9432, Both the ADA language and the 432 
architecture address many of the problems associated with 
large scale software development ocrojects,. This resulted in 
eeeveral architectural constructs which directly support many 
ANA lanaquage features, 
io) Oo eet TayipeanG 
The object ortentation of the architecture plays a 
major role in language support, Every object is tyved by 
the compiler or by the hardware to indicate its intended 
use, This allows a natural separation of drocedure objects 
from data objects, In addition to ’intended use’ typing, the 
opjects are also classified as to thetr internal structure. 
feos structure can be one of two types, access obfects or 
data objects, The access object {iS an array of access 
descriptors (to other objects) while data objects are 


structured Sroces. Of cata information, Access objects 
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contain only access descriptors and data objects contain 


only data, This is represented in Figure 3, 
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Figure 3, ADA#432 Object Tynes 


As shown in Figure 3, any set of iLAPX=432 ohbtects can  05be 
represented by a directed graph containing access object 
nodes and data object nodes, This notational convention 
serves aS a useful model for representing execution time 
objects and their relationships to corresponding ADA 
proorams, It is important to realize that an object can 
exist as the subpart of another object and vet be logically 
different, Such an object that is ohysically contained 


inside a parent object is termed a refinement of the parent 
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object. Tne refined opojects are physically subeparts of the 
parent object, yet they can inherit the full privileges of 
objects, as if they were ohysically distinet from the 
parent. In the case of multiple refinements, they can behave 
as if physically distinct from other refinements of the 


parent. This is illustrated in Figure 4, 
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Fiaqure 4, Refinements 


Bre - e t 

Common data structures and procedures can be grouped 
together using the ADA vackage corstruct., The INTEL LAPX=432 
uses a domain object to represent an ADA package, The domain 
object, like a package, is a collection of data objects and 
procedure objects (hence it ts of type aecess), This can 
best be illustrated by tne following example of an ADA 
package definition and tne corresponding {1APX#432 object 


representation shown in Figure 5, 
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package SIMPLE fs 


Tope t integer | ewe aweeencccescaceaa | 
procedure ADD(1,4,k)?3 I Domain Object | 
procedure SUBTRACT(1,3.«K)3! SIMPLE 
end SIMPLE Jo] weneeneas | ceeece | aq | 


i i | 
package body SIMPLE {tis i l ! 


procedure ADD(C1i,4,k) is V V V 
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procedure SUBTRACT(i,j,k) is 
beaqin 
K se Leq; 
end SUBTRACT? 
end SIMPLE; 


Figure 5, ADA Packace and {1APX=432 
Moject Correspondence 


Bence obJ@ects can be refined, it is possible to refine a 
domain object to create domains of a package with different 
access richts, This mechanism very nicely supports the 
public and private access rights defined in ADA, A uSer is 
Given aecess to publie information by creating a refined 
object with access deseriptors to a refined domain whieh 
contains only public data, 
3. ~) @ a - 
An LAPXe432 procedure object consists of executable 


eode correspondina to an ADA procedure, The procedure object 
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also contains information required to form the activation 
record or context object which is created on crocedure 
invocation. Procedures may be invoked in either interdomain 
or intradomain contexts. The interdomain context means that 
a procedure in one package (domain) ts calling a procedure 
in another package (domain). Intradomain procedure calls are 
simply calls within the same package, 
4, Activation Records 

A block sfruectured languace such aS ADA can make 
efficient use of activation records, The LAPX#432 supports 
the use of activation records via context access objects and 
context data obojects. The context access object represents 
local reference variables and tne context data object 
represents local data variables of the activation record, 
ome LAPXe432 {instructions “procedure call’ and ‘’vorocedure 
return’ create and destroy context objects, 

Se Tasking 

One of the important multiprocessing features of the 
ADA language is the concept of @ task. Tasks are directly 
supported in the LAPX=432 through the use of dispatching and 
eommunieation port objects, The communication port object is 
a message queue that acts as a buffer between processes that 
may be executina concurrently. [t’s function is to allow 
inter=orocess communication. A dispatening port is a svecial 
form of a message aueve in which a process object may snend 


time waiting for the arrival of an available processor, or 
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where a processor object awaits the arrival of a process, 
These operations are performed in hardware which allows for 
very efficient coding of the ADA tasking model, 

It may be surmised from the previous discussion that the 
language ADA and the INTEL {APX-432 Nave several common 
foundations, This- was undoubtedly intentional, The 
microprocessor is designed to be vorogrammed using high level 
lanquages such as ADA as the development languace, No 
assembler is planned or under development by the 


manufacturer, 
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IV. BENCHMARK PROGRAM TIMING RESULTS 


A. BENCHMARK PROGRAMS 

The benchmark programs were obtained, for the most part, 
from the CFA algorithms referenced in Chanter II, Section E 
"Benchmark Evaluation Deseription", Some programs from a 
noneCFA related study were also used so that an objective 
timing comparison could be made with other processors, 

1, Methods tised 

The programs were coded in ADA, compiled using the 

INTEL ADA=432 compiler on a VAX = 11/780 host computer, 
linked on the VAX = 11/780 using the INTEL 432 linker, and 
downloaded to a floppy disk via the INTEL asynchronous 
communications link, Execution of the downloaded object code 
was performed using the INTEL Debuager and Execution 
software package operating on a INTEL MDS System 800, The 
INTEL MDS svstem is required to load the executable code 
into the INTEL 432/670 system for execution on the {LAPX=432 
microprocessor, The system setup iS Shown Figure 6, 


ii. OOOO SaaS ee 


VAX 11/780 VAX 11/780 MDS=890 432/670 


[ | uae > | [ en2> | | «> | } 
| | | | | 


compile link download execute 


— a — Si A A — Tp — lag a) al I Re i a ee Ee 


Figure 6. CDS System Overview 
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In order to actively simulate large scale software 
development (and to exercise some unique ADA features) all 
the coded CFA programs were developed in such a way that the 
proagram specifications were separate from the program body, 
The effect of this decision was twofold: 

1. Programs could be written and debugged indepen= 
dently by both authors. 
2. The concept and value of using a separate program 
soeciftication construct could be demonstrated, 
A careful inspection of each benchmark program will reveal 


that it consists of three orimary parts, These parts are; 


1. Package specification. 
2. Package body, 


3. Main or driver procedure, 


The driver routine {is needed to initiate a user process in 
the 432/670 system. The oroarams were desianed so that the 
user could control the number of times the benchmark was 
invoked. This allowed for an effective averaging method. 
For example, the benchmark could te executed 100,900 times, 
accurately timed with a stopwaten, and then the total 
elapsed time could be divided by 100,000 to obtain the 
average execution time for the procedure, Each program 
writes a start and a stop message, including an audible 
“bell’ to indicate when to commence and end timing. In 


order to effectively fsolate the odorocedure invocation timing 
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overhead from the benchmark timing, there were usually two 
different driver routines with each benchmark program, Each 
proaram, when executed, would request the number of times to 
perform the algorithm in question. This request could come 
from the driver routine or from the benchmark procedure, If 
it came from the former then the time measured included the 
time required to invoke the procedure, A timing request from 
the benchmark procedure ineluded only the timing reauired to 
perform the algerithm, The difference in the two times was 
then a measure of the procedure invocation overhead, Note 
that this method would not work with a recursive procedure, 
Further discussion of these methods and the mechanics 
involved can be found in Chapter V, "CDS 432/670 User 
Evaluation.", 
2. Applicable Algorithms 

The ADA#=432 compiler (Version 1.0) does not support 
the full ADA Jlanauage. The manufacturer has added some 
extensions to the compiler but it presently laeks many 
important ADA features, Some of the sifanificant compiler 
limitations are as follows: 

1. Fixed point and floating point types are not ime 
Dlemented, 


2. Tasking, as defined in the Reference Manual ‘for 
the ADA Programming Language, is not implemented, 


3. Array operations, such as concatenation, assign= 
ment, and boolean operations are not implemented, 
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4. Dynamic arrays and dynamic strings are not implee 
mented, 


5. Run time ehecks are not operational, 

6. Exceptions are not implemented, 

7. Record representations for records containing 

fields of tyoe access are not implemented, 
Although the above compiler limitations are rather severe it 
was still ovossible to code several of the CFA algorithms in 
ADA-432 and most of those coded could be executed on the 
{APX=432, The lack of a hardware interrupt orevented many of 
the CFA benchmarks from being coded, Future releases of the 
432/670 system are supoosed to provide the facility of an 
interrupt throudqh the use of an attached orocessor. This 
feature was not available in this release of the 432, A 
short description of each of the executable programs 
follows, The complete source code can be found in Apnendix 
Ce 
@e Character Searen 
This orogram searcned a given string for the 

occurrence of an araument string and returned the location 
of tne araument string, if {1t was located, The program was 
geaec from the algorithm in thé original CFA study, The 
eegoritnhm is listed in Apoendix D. The strings were read 
into a variable of tyoe STRINGS8O, which is an ADA#432 
predefined type required for text I/0Q. The strings were 


then decomposed into individual characters and assianed to a 


45 





1 by 256 character array. This method.was necessary because 
of the orimitive state of the current ADA#=432 text I/0 
package, The program was made interactive to allow for many 
searches to be performed in any given debuagina/execution 
session, The data structures, calling conventions, and a 


sample expected result are shown in Figure 7, 


Seareh Strings: 


J TSS | SS FS es Oe Oe 
'MloIniatalyt,!' tJluintiel I71tint,! Ii1I9l7 tél 
ett | ite tT Pet ot htt tl gl ct a Ed 


| wen eeon ones onsen eenonecaeeeoeee Gee eeenaana a | 
if: 2 3 + 5 6 7 8 9 @ @ e @ @ t t a : e 8 e 22 
Argument string: 
jelelel 
Idialvl 


72 8 


Searenh lenath := 22 


Argument lenath := 3 


SEARCH(Searehilength,Arg.wlengqtn,Searchastr,Arge.len,10c) 


expected result $: loe = 3 


Figure 7. Cnaracter Search 
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Two versions of the program were used. One 
version included the time required to invoke a procedure 
while the other version did not include procedure invocation 
overhead. As will he shown in the timing results section of 
this chapter, procedure invocation is expensive, 

b, Quicksort 

This program performed a quicksort on a given 
array of records, The program was coded using tne CFA 
quicksort algorithm in Apsoendix D, The records sorted 
eonsisted of an Integer kev field (to be sorted on) and a 
ecnaracter field associated with eacn key, A pietorial 
representation of the data structure and the sorting process 


and calling convention is shown in Figure 38, 


Arrayl 


1 4{D 1 


) 1daA t 


Stee! 


1r2itsBst 


fs lc. 


Array2 


1 1toaA | 


Peewee PB 


| wee | wee | 


esi | 


41D 4 


a Es! 


Calling convention: SORT(Array!1,Array2) 


expected result : arrayi is sorted on 
the integer field 
to make arrav2, 





Figure 8. Quleksort 
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Tne program was written to act int#ractively with the user 
to allow for several different runs per debugging session, 
Two versions of Quicksort were used, One was an iterative 
sort, the other a recursive sort. The timing results show 
that the procedure invocation overhead of the recursive sort 
was significant. 
¢. Hashtable 

THis program located the vosition a key would 
eceupy in a hasn table. An example of the data structure 
used and the calling conventions are shown in Figure 9. The 
a@alaorithm for tnis program was obtained from the second CFA 
Study by Dietz(i] and can be found in Appendix D,. 

TABLE 


HASHES (key) eoe2 | eweeaea | 
| | 


| | ssmweewe | 
Vv { 
| -eacaaoe | 
| 
| ; | 
| ; { 


calling convention: 


position := HASHES( Key ) 





Figure 9, Hasntable Data Structure 
and Calling Convention 


Since this program used a function, there was only one 
version written, The procedure invocation overhead is 


included in the timing results. 
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d. Digital Communications Processing 
This eeor an sent a message to a given output 
buffer, The algorithm was taken from the second CFA study by 
Dietz (1) and is located in Appendix D. The data structures 
used for the program anda tyoical calling convention are 


shown in Figure 10, 


eR ee SOTO a aa ee ee oe 


meaaootrs | { A spointer to a messace record, 
messades: 
i 4 | 3 | This is a message | 

a Sy & 


I j | 
destination connection message data 


destinationatbl Bure col bufferwarray 

| eneewwcans | | sesanwe | | sesanecae | 
I 1] | A | 

| sew wewenne | | eaawna| | maameancen | 
2 | { 2 | 2!'This is al 

{ | | | 1! message | 

J weanannnowee | | samawm | | maaewnea es | 
1 | 31 "2 31 
o | wenwwacaen | | eaanae | | waa aasn | 

i | | 

destination indexes Connection contents of 
Gestination.tbl indexes the indexed 
which then points ENe@ hut. cOL. buf.tbl used 
Eos specific to locate the 
Suc.tSl array, approoriate 


bufferwarray 
Bosteilone 7 oO 
Dut message 
data, 
calling convention: 
FORWARPD(Cdestination,connection,mSguptr) 


AP a-Si. LD. A gg ee SR a 


Fiaure 19, Digital Communications 





The program interactively queried for the message 
destination, message connection and the mnessage text. This 
allowed for several sample runs to be oerformed during a 
debuqging session. 
e, Memory Usage 

A close inspection of the ADA source code in 
Appendix C shows that many of the data structures are auite 
sfall. This is intentional, and necessary, Baciy ino tne 
course of this investigation it was discovered that programs 
would compile correctly but execute in an unpredictable 
manner, Tne problem was found to be in the amount of heap 
memory allotted to @ user process in Version 1.9 of the 
IMAX=432 operating system. TR@® memory allocated was not 
Becr@meliy large, and could often be used uo without anv 
indication to the user what was wrong, The srearam Eate 
Memory was written to demonstrate how fast memory was used 
uP. The Drogram was fairly simple in that all it did was to 
create an array of 59 characters and a pointer to the array, 
This program was also written in two versions, one that 
ereated the arrays recursively, the other iteratively, Tne 
expense of context creation ina recursive procedure was 
Shown to be very great. Only nine recursive calis could be 
made before the program used all of the available memory and 
the system crashed. The iterative version did much better 
and 199 separate data structures were created before all 


available memory was exhausted, Of particular interest to 
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the user is that there is no indication as to what is wrong 
when the memory is used up. The display {s "blank" and all 
efforts to use the debug facility resulted in a system 
response of "no current process", In summary, the user must 
laboriously inspect the program object code (the MAP file) 
and arbitrarily set breakpoints in tne code to determine 
what the cause of the fatal error is. This problem is 
elaborated in Chapter V of this thesis. 
3. CEA Coded but not Executed Programs 

Two programs from the first CFA study were coded in 

ADA and executed on an ADA=ED compiler to check for correct 


program execution, These orograms were: 


1. Linked List Insertion. 


2. RungeeKutta Integration, 


Unfortunately the present ADA#432 compiler does not support 
the floating point data type necessary for tne integration 
Program; nor does the ADA#432 compiler Support records with 
access types, which {is necessary for the linked list 
insertion program. The ADA source code for these programs is 
located in Appendix cC for easy reference to allow for 
possible conversion when a more complete compiler is 
released, 
4. Non-CFA Related Programs 
Since the CFA study never actually timed the 


benchmark programs in terms of execution speed, it was 


=)! 





decided that a pnysical comparison of the fAPX"432 with 
other processors would be useful. A previous evaluation of 
the 1APX-432 by Hansen (3) in June 1982 provided three 
convenient ADA programs to use, These programs were obtained 
from the Computer Selence Department at U.C. Berkeley, 
modified slightly to conform with the current ADA#432 
compiler requirements, and then executed and timed on the 
432/670 system, The three proarams used were; 

1. Search: Search a 120 character string for a 15 
character subestringa,. 

2. Steves; Compute prime numbers, 

3. Acker: Calculate Ackerman’s funetion with argue 
ments 3 and 6, This is a recursive computation 
requiring more than 170,000 procedure calls, 

The complete ADA source code for the programs can pe found 
in Aopendix C, The timing results are summarized in Chapter 


tv. 


B. TIMING PROCEDURE AND RESULTS 

All the CFA programs were written so that the user could 
write the arguments from the keyboard and select the number 
of times fhe orogram was to execute, Dividing the total 
elapsed time by tne number of times the vprocram executed 
gave an average value of execution time for the particular 
benchmark. Procedure invocation overhead was subtracted from 
the non-recursive procedures and both timing values are 


shown in the following  diseussion. In addition, the 
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parameters used and the numbder of executions are also 
listed, 
1. CEA Benchmark Program Results, 

The following sections describe the parameters used 
for each benchmark executed, the number of executions 
performed, the total elapsed time (in seconds), and the 
calculated execution time for a single run. Note that the 
program name corresponds to the ADA=432 source code for the 
respective program in Appendix C. 

a, Character Search 

The parameters used in this benchmark timing 


were: 


SEARCH STRING : Monday, June 7th, 1976 
ARGUMENT STRING 3: day 
SEARCH LENGTH ele 


ARGUMENT LENGTH ¢: 3 


EE OES See ae ee eee ee 


Program Number of Elapsed time Time 
name executions seconds nsec 
CHARS! 100,000 315.6 Sic 
CHARS2 100,000 142.3 i,4 


6S Rn |_| a OR EE il Ne 


Figure 11, Character Search Results 
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The program CHARS! included the time required for 100,000 
procedure invocations whereas CHARS2 did not. For this 
benchmark, Figure 11 shows that the procedure overhead was 
more than twice the time to perform the algorithm! 
db. Quicksort 

Two forms of the quicksort algorithm were used, 
one recursive , the other iterative. A twenty element array 
was sorted, The worst case array was chosen, that is, all 
the elements were inversely ordered, Fisure 12 represents 
the parameters passed; unsorted arrayi was passed to the 


Procedure and the sorted array2 resulted, 


a aa ae ewe ee eee ee ea es ee ee ee eee ee eee 


arrayl : 


Ai sen oes Pett tO 9°8 7 6 S$ 4 3 2 2 


array2 3: 


oes 76 Boo | Oem 2 23°14 1S )16 17 18 19 20 


Program Number of Elapsed time Time 
name executions seconds msec 
QUICK1 1000 55,8 -o6 


(recursive) 


QUICK2 1009 40.5 e 41 
(non recursive) 


a ee Ne a eee ee i ee 


Filaoure 12, Quieksort Results 





As expected, the recursive procedure took considerably 
lenger to execute, This is not too surprising since the 
overhead of procedure invocation is included, 
cc, Hashtable 

The nashtable algorithm was implemented as a 
Funetion. The timing results therefore include the function 
call overhead. This funetion used the sample hash table from 
the CFA study anda Key value of 41 was used as the araqument 
of the function. The hashtable’s tnitial values, calling 


convention, and timing results are shown in Figure 13, 





Key ioe, O55 She s5 Sas 86 0 £33 183 | 


index eo. to °3 4 5 6 7 8&8 9 | 


position := HASHES(41) 


Program Number of Elapsed time Time 
name executions seconds msec 
HASH1 100,009 252 2a 


4.48, 1h_.40.4n._ 2. SBP, -_  ___ _ _  e _ 
Figure 13. RBRashntable Results 


d. Digital Communication Processing 
This erocedure sent a tnirty character message 
to the output buffer, Fiqure 14 represents the data values 


passed to the procedure for processing. 
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msgeptr |! | 
message 
| emanaewarae | ewa @gaaq we | Sa gma eaeqgeneaeqtaq@ae Gaeta @Baagaag aeuaaa a | 
| 10 | in { This {1s a thirty character msqi 
destination connection message data 
Pregram Number of Elapsed time Time 
name executions seconds msec 
DCOM1 100,000 286.9 2.9 
DCOM2 100,000 201.6 20 


¢ 





Figure 14, Digital Communication Pesults 


In this case the procedure overnead was nearly one third 
that of performing the alaorithnm, 
2. Non CFA Program Results 
Amn e@arlier study of the 432 was performed by 
Hansen(3] at U.C. Berkeley, Several benchmark orogqrams were 
coded and executed on various machines and in several 
different languages. A Summary of those results is snown in 


Pogure 15S. 
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Pa Tm ke kk kk ek ee ke nk ek 8 


macnine | language | program 
| name 


| Searcn | Steve | Acker 


evnevseees | eeeeeneanen | eentenens | ceaenee | eae seeeeren 


432 | ADA { 14.2 {'{ 3200 | 260,000 
4 MHZ | | f | 
eenenneees | econeveseneen | ceaneneen | eveeane | saneaeeanaa 
8086 { PASCAL 1 ves 764 | 11100 
5 MHZ | | | 
eanennenea | enennneance | ce eeneen | enn eeee | en nna eeeee 
A8000 | PASCAL | wes | 196 | 2750 
16 MHZ | { 
sea nnnene | eeeeeneeee | eeeeseces | seeeees | sees seeewe 
VAX f PASCAL te te 259 | 9800 
11/730 |! CV¥S) | | 


| i All times are in msec 


These results are from a study by HANSEN[3] 

waien were performed on a 432 verston 2. The 

Processors manufacturers were 3: 8986 = INTEL, 
68000 = MOTOROLA, VAX 11/780 = DEC, 





Fiaure 15, Previous Non CFA Timing Results 


An attempt was made to duplicate the resuits from 
the earlier study by executing the benchmark programs on the 
CDS 432/670 system, The pdrograms that were received = from 
U.C, Berkeley would not compile under version 1.9 of the 
comefler supplied with the 432/670 system, No parameters 
were oassed in using these tests, they were {neluded in the 
code. An examination of the ADA source code in Apoendix C 
will also reveal that no effort was made to seoarate orogram 
body from program specification, Tne results from our 


timing are snown in Figure 16, 


ay 





| 
{ 
machine | language | program 
! name 
! { 


| 
| SEARCH |! SIEVE | ACKER 


! ! | | 
432 ADA aie, 7 


2000 
8 MHZ i V1.0 
| 


| 
| 


Figure 16. Mon CFA Timina Results 
ADA Version 1,90 


Extreme caution must be exercised when comparing these 
values toa the previous study, Svecifically in the case of 
the STEVE and ACKER orograms, The limited stack heano 
avallable prevented implementina the code exactiy as done by 
N.C. Berkeley, The results of the SEARCH benchmark are very 
interesting. The three proaqrams received from U.C. Berkeley 
required some modification before they would comoile 
successfully on the Intel ADA#432 comoiler, Mare 
importantly, our results generally include the time required 
fer procedure’ invocation. In some instances, notably our 
algorithm implementing the character search, we also have 
results which do not include procedure invocation overhead. 
Lastly, whereas we used the concept of packages in arriving 


at the coding of our benchmarks, the U.C,Berkeley orograms 
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did not. These differences are easily seen by referring to 
Appendix C, 

It 1s not clear whether the results by Hansen([3] 
include procedure invocation overhead, However, since the 
432 used in this thesis nad a 5 MHZ clock rate (with ane 8 
MHZ system e¢lock) as opposed to a 4 MHZ clock rate in the 
Hansen study, one would suspect that running the same 
program witn the same data would give at the least, 
comparable results, To our surprise, this was not the case, 
Initially, we timed the SEARCH algorithm sent from Berkeley 
"as is", This was timed at 23 milliseconds, quite a 
difference from 14.2 in the previously cited study, We then 
modified the Berkeley algorithm so as not to include string 
initialization each time, Since our first timing was so 
different from tne Berkeley study we thought that string 
initialization should not be included in the results, The 
second test was made by just timing the Rerkeley search 
function alone, This included procedure invocation overhead, 


The result is listed in Fiaqure 16, 


Ce. SUMMARY OF RESULTS 

The data in the previous figures pertinent to the CFA 
studies, is summarized in Figure 17, It is believed sy the 
authors that the following times represent realistic 
execution speeds available to a user performing in the 


working environment of the poresent 432/670 system, 
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Program execution speed 
description msec 
Character Search 1.4 
Guieksort (recursive) 0.56 
Guicksort (none-recursive) 0,41 
Hashtable lookup 25.5 
| Sgauae See ee agaggaea ee geaegeep@ea@ee @Seg@aGQGeaq_aggee BSeegeeaLBes eae ws ws ws 

Digital Communication 260 


- leila ii A th Aa TI i — i ah i ie ih i io a i ay i na cal RB 


Figure 17. Execution Speed Result Summary 


The data reported above does not inelude the procedure 
invocation overhead, with the exception of the recursive 
Quicksort and the function Hasntable Lookup. It needs to be 
emphasized that the numbers are only ’rules of thumb’ that 
should be used in describing the execution speed of the 
LAPX=-=432,. Compiler differences, and just as importantly the 


argument used in the algorithm, can significantly affect the 
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execution speed, For example, if tne c¢haracter string 
searched for in the Character Search is near the beginning 
eof the seareh string vs. near the end of the search string, 
the results can vary by as much as a factor of ten. (The 
lenath of the string searched also plays a significant role 
in determining execution time), The exact araquments passed 
and the calling conventions used have been described in 
detail (Chapter I[V.A)} for future reference and comparison, 
The values in Figure !7 represent an aporoximation to 
the time required to perform a given algorithm, In order to 
eross check and verify the timing results, an effort was 
made to time a single {APX-432 instruction, This was 
accomplished by writing two test oroaqrams, Ti00 and T101, 
whieh differed by a single line of source code, Tnat is, 
T100 executed "A 3:= 8 2 C" one hundred tines and T1101 
executed "A s= B = C* one hundred and one times, An 
examination of the MAP file (the compiler outodut) revealed 
that the code differed by one statement. That statement was 
"Sub.1", an LAPX=432 mnemonic for Subtract integer, The time 
difference between the two programs could then give a figure 
for the execution speed of the single sub.ai instruction, The 
measured sdeed could be directly compared with 6 previous 
study (8) whieh timed individual instruction speeds on a 
4MHZ {1APX~-432/100 Versioni. The results are summarized in 


meeaure 18, 





WD ee OOOO eee ee ee SS See Ee ew ae 


Program Number of time(sec) difference 
name sSubui executions 
T100 { 40,000,000 ' 777,8 | 
6.90 
Ah alte ya) i 40,400,000 t 784,7 | 
execution time 
subi = 6.90 / 400,000 = 1.73 X 105 see 
Supa. Sb a: 
Version 1 5MHZ Version 2 5MHZ 
estimated cycles measured cycles 
ra | 96 


Estimated cycles are from an earlier study (8) 

on a 432/100 system and represent a projection 
based on measured results. Version 2 measured 
cycles are the result of the product of execution 
j time and the clock rate, 


i ati SI a Tt IE = ie mic Bie om! Gli aaa ple! hao ta ella bin! Bi atte Stage et ee ee Ee 


Fi{oaure 1&8, Individual Instruction Timing 


AS can be seen in Figure 18, the measured speed of the 
subei instruetion in this study is in good agreement with 
the previous results. The differences can possibly be 
@ecounted for in the facet that two different versions of the 
microsrocessor are being compared, 

An attemot was also made to eliminate the effeets of 
Eaq@ad time", or "time out" in the execution of a dDrogran, 
This time out is the onertod during whieh a orocess ts 
suspended while the dispatching port is ecnecked for another 


process to be assigned to a processor, Normally a process is 
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given a default value of 0,2 seconds of dedicated processor 
time between time outs, Since only one program was executing 
at a time, it was not believed that the program timing 
results would be significantly affected by the dispatching 
port check overhead, To verify this, a modification was made 
tro the INTEL supplied ADA package PSERP.MBS, The 
modification increased the time slice from 9,2 seconds to 2 
seconds. Similar poroarams that differed only in the time 
slice period (0,2 seconds vs 2 seconds) executed within 0.5 
seconds of each other over a total execution time of 200 
seconds, This confirmed that the time slice period between 
dispatching port checks was not significantly interfering 


with the benchmark results, 
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Ve. CDS 432/670 USER EVALUATION 


In the process of working on this thesis both authors 
felt that a section devoted to constructive criticism of the 
INTEL Cross Development System would be appropriate, 3y 
Cross Development System we mean the INTEL ADA comoliler, 
linker, downleadiag and execution scftware and cerrespondina 
documentation, Additionally we conelude with some of our 
thoughts on ADA. We understand that many of the problems 
addressed here are not sermanent, and very likely many of 
the items we have found to be mysterious or irksome may have 
already been corrected in a later release, 

The INTEL 432/670 system can be conveniently divided 


into four major comovonents: 


1. Comoller, 
2. Linker, 
3. Downloading and Asynchronous Communication, 


4. Debuggina and Execution, 


The following discussion will treat each component in turn, 


stating what positive and negative attributes we found, 


A, COMPILER 
The ADA#432 compiler does not support full ADA, The 


language limitations are listed in Cnapter IV, Of these, the 
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lack of floating point number Support was felt to be 
extremely burdensome to this thesis, A great many of the CFA 
measures are focused on floating point manipulation, as are 
many real world applications, At the machine level, the 
LAPX=432 has outstanding floating point support, such as 
multiply, divide, and square root machine instructions, The 
lack of compiler support for floating point operations 
prevented us from testing oroarams in an area wnere the 
LAPX=432 snould provide outstanding oerformance, 

The present text I/0 vackage orovided in the ADA#432 
compiler can best be described as primitive, The user ts 
Given a choice as to how messages can be input and outsut to 
and from the screen, that is, the message can he 1, 10, 29, 
Sewor 80 characters long, and of no other it€éngth. Counting 
the nmumper of characters in one’s input and output text 
Sianificantly detracts from the art of proaramminga, 

Compilation of a user’s ADA source code is performed on 
the host VAX 11/780 and it proceeds at a respectable rate, 
the turn around time was always less than a minute, The 
number of compilation errors is disolayed at the end of 
compilation, Nowever the reason for the errors is not. To 
evaluate the compilation errors, INTEL has supplied a very 
useful report faellity which fs an image of the original ADA 
source code with errors identified by a diagnostic message 


and code number, Unfortunately, many of the error code 
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numbers in the INTEL reference manual just repeat the same 
diagnostic error message, with no further elaboration. 

There was ome very frustratina aspect of the compiler 
output to the screen. That is, after compilation is 
complete, there is no messaqe as to what unit was just 
compiled. Since the compiler output often scerollis the 
screen, this leaves it up to the user to remember what unit 
nas just been compiled, ADA programs consist of many units, 
and in more than one instance we found ourselves recomoiling 
a unit that had just been comefied. A very simple solution 
to this would be to output the compiled unit’s name as the 
last line of output along with the error messages. 

AS with most new comoilers, there are some errors. The 
more Significant of these are the tvpe that allowed 
compilation of code representing features that are not yet 
implemented, For example, array assignments are not yet 
operational, yet a source Code program containing them 
compiles with no error messages, Execution, as exoected, 
does not occur, Most of the ADA restrictions are well 
documented in the error report file, however, it only takes 
one or two whieh are not identified to cause siontficant 
problems in debuoging a program, At least one type of error 
crashes the comoiler. That 1S, €a program which needs a 
large data structure may never compile and furthermore the 
user will never be informed as to the reason for the 
failure. This problem occurred with the following program 
Omit : 
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type item is 
record 
key : integer; 
data : cnNaracter; 
end record} 
type array.wone is array(1,.2000) of item; 


beqin 


When array.one had 2000 elements the Program unit c¢rashed 
the compiler, Lowering the number of elements to 200 


allowed satisfactory compilation, 


B. LINKER 

The linking process of a users program is tedious. A 
separate link program needs to be written for each program 
enat is to be linked, The time to Ilink a #oprogram is 
considerable, usvally in the ranqe of two to three minutes. 
Many default parameters occur in the linkina process which 
can be changed by directives in the users link program, No 
Problems were experienced with the default values, but 
depending on a default value for proper oSrogram execution 
can easily lead to difficult dehuqging errors in future 
prodram maintenance. In our opinion all the directives 
should be required to be explicitly stated, 

The linker Ras at least one ambiguous characteristic, 


After a successful linkaace, a message is written to the 
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screen which states "LINKAGE SUCCESSFUL". This message may 
also be accompanied by one or more warning messages, In 
every case that we experienced, if a warning message 
eccurred during linking then the program would not execute, 


The message "LINKAGE SUCCESSFUL" can be very misleading, 


C. DOWNLOADING 

The process of downloading programs from the host VAX 
11/780 system {s probably the biggest drawback to the 
432/570 system, Since the iIMAX operating system is part of 
the downloaded object files (EQD), the files reauiring 
transfer are quite large. A typical small ADA program (less 
than 100 lines of source code) takes nearly twenty minutes 
to download at 2400 baud, This makes program changes very 
time consuming, Even if a 9600 baud line were used, the 
entire process of correcting source code, res#comoiling 
affected modules, and then downloading them, reauires a 
Significant amount of time, There {is a proaram called 
UPDATE for merging a recompiled module of a proaqram with 
the existing EOD fille, Tne smaller rescomoiled module is 
much faster to download, about seven minutes, but the UPDATE 
program takes about 3 to 4 minutes to execute, The time 
saved was not considered significant to warrant use of the 
UPDATE feature, Especially since a new link program would 
nave to be written each time it was desired to recompile a 


Pertlion of a verogram, 
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De DEBUGGING AND EXECUTION 

Our impression of the debug facility was favorable, It 
allowed for access to the program structure at an assembly 
language level, This did not allow any type of assembly=-like 
programming but did provide a means to locate errors in our 
source code by mapping the error location to a source code 
statement mumber, A very useful utility is the LOG proaqran. 
This allows everything that was inPut or output at the 
terminal to be logged for future reference, The debug 
facility could be made much ~more user friendly bY 
implementing the ADA exception features, At present, the 
lack of axceptions means that run time errors may not be 
reported, and indeed may cause the system to crash with no 
indication to the user as to the cause. AN example of this 
occurred when one of our oproarams attemoted to index an 
array outside the declared array bounds. No error messages 
were reported, and the system crashed, 

The execution of a program was difficult to initiate, 
The following sequence of commands represents the minimum 
time reauired to execute a program after the oower {s turned 
on and the ISIS=*II operating system is booted, The times are 
approximate and they depend on the size of the orogram that 


is going to pe executed, 
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command time required 


RUN WORK sFOs As) ne Cele 
RUN DES3432 1 min. 
INCLUDE DEB432,TEM toma, 
INIT 1 min, 
DEBUG "userprogram" i min, 
START 


Once the system debuager is loaded (once per session) things 
proceed a little faster, Only the last three commands of 


INIT, DEBUG, and START are required per program, 


E. ADA IMPRESSIONS 

One of the many interesting facets of working on this 
thesis was tne exposure to the new Dod language ADA, 
Inasmuch as our us@ of ADA was limited to the benenmarks in 
this thesis, plus the fact that we dealt with a compiler 
which did not fully implement the lanquaqe, our impressions 
are limited, However, the features of ADA we did exercise 
left us with some favorable impressions. 

The feature we used and liked most was the ability to 
separate the specifications of a® program from the 
corresponding body of the proaram,. The package feature of 
ADA was used to do this. A specification package is simply 
the formalizing in ADA of what the interface of the program 
is to be, t.e., the “what” of the program, The body package 


on the other hand is the formalizing in ADA of the manner in 


7 





which one plans to implement the program, 1.e., the “how’ of 
the program, Tne contribution of this separation is 
twofold: 

1. Given a specification package, a programmer is 
free to imolement the program in the manner he or 
she sees fit, so long as it satisfies the specif- 
ication, or interface, 

2. Users of a particular program or programs need 
only be given the specification package in order 
to discern what the particular code can do for 
them, The “’how’ of the code, or the body package, 
need not concern them, 

Using this technique in very large software projects 
should have a siqnificant effect on software develooment and 
maintenance, In our small scale projects the Separation of 
soecification and body allowed for easv parallel develooment 
of the benchmark programs, The acceptance of ADA by DoD 
computer personnel could be seen to lead to: 

1. Tne arowth of software libraries with specifica- 
tion packages as the user interface to the lis 
brary, 

2. Greater productivity among ocrogrammers, For ine 
stance, suppose a decision is reached on what a 
particular piece of software is to do, This 
"wrhatt is formalized in ADA, and aiven to the 
Programmer(s). The oragrammer is now free ¢to 
ring all of nis or her abfllities to bear on suce 
cessfully implementing the body, or the "how" of 
the piece of softwars?, 

Botn of these abllities are generally regarded to be very 


worthwhile, something which ud to now has been pursued with 


no great deqree of success, SUDDOrELNAG and thereby 
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facilitating this feature of packages is the separate 
compilation ability of ADA, while still enforcing strong 
typeechecking of interfaces, That is, making sure that 
parameters in the body package are of the exact same kind as 
those delineated in the specification, which may have been 
compiled some time before actual coding was ever begun on 


the pody. 
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VI. CONCLUSTONS 


In its present maane the INTEL Cross Development System 
(CDS) is very much a development teol, Areas which we feel 
could be changed to improve the user friendliness of the 
system have peen presented in the previous chapter. 

As an execution vehicle for the ADA language, the 
processor seems especially well suited. However, the 
incompleteness of the comoiler did not permit us to 
rigorously exercise the 432 as much as we wanted to. Though 
the 432 and ADA seem especially well matched, it is not 
reflected in pregram execution speed. An objecteoriented 
architecture, which also incorporates system management 
facilities in hardware, undoubtedly must have some 
drawbacks, In this version of the 432, this was 
unfortunately reflected in execution speed, As an aside, 
when the compiler comes to support floating point 
operations, benchmarks which exercise floating ovoint 
manipulations should provide some interesting results. As 
elaborated previously, hardware supoort for floating point 
operations in the 432 are outstanding, 

The lack of a hardware interrupt is a handicap that 
should be capable of being overcome through the use of the 
attached processor. This feature was not overational on the 


432/670 system and therefore could not be tested, 
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The timing performance of the SyStem, at first glance, 
does not present a very favorable impression, The benchmark 
programs that were compared with the previous study by 
Hansen{3] confirmed that the 432 is slow in it’s execution 
speed, Execution speed {is but one of many measures of any 
computer architecture, It is, however, a measure which 
readily lends itself to numerical analysis as opposed to 
qualitative fearures which do mote. iats subjective 
qualitative category can include such items as the amount of 
fault tolerance and protection available, 

The multiprocessor capabilities of the 432 provide a 
ease study in some of the issues whieh must be addressed by 
any system using multiprocessina. Moreover, the system in 
general soermits one to analyze the more rasiec concerts of an 
ooverating system, Processes, intereprocess communication, 
ready, runnina, and blocked states are al] generic terms to 
the architecture, Any study of the processor’s architecture 
eannot help but to provide an excellent insignt into these 
concepts, 

Finally, the architecture has been designed to be 
proqrammed in a hich level lanaguage only. As the comotiler 
inefficiencies are removed and the cost of procedure 
invocation is lowered the 432 should show a ~-Mmarked 


improvement in it’s overall performance, 
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APPENDIX A 


HARDWARE DESCRIPTION 


This thesis used @a& modified INTEL MDS SYSTEM 800 
interfaced with the LAPX-432 execution venicle., This setup 
required 4a special circuit board to allow communication 
petween the MDS 800 system and the 432/679, The chassis 
name, slot numper, and board number of the system components 
used in this evaluation follow. . 

Card cage number to circuit board identification 


MDS=800 poard descriptions: 


SEQ ge es @eesQ wae seas eaeeeewseeese See eae es eeaeggaees e2e@g@awseaeean,neeeeaa w& w= & 


oye RPB=86 


17. 432 IP INTEL 432/670 172080-006ereyv H 
S/N#xp=-000198 
18, 


432/570 board description: 
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5S. MEMORY INTEL 112340"004 REV C 4112354"001 REV c 
S/N 000279 

6, MEMORY INTEL 112340"004 REV C 112354001 REV C 
S/N 000262 

7. MEMORY CONTROLLER INTEL 172075005 REV E 
S/N #-xp-9000033 

8, GOP INTEL 432/601 905 REV F S/Nexp=-000187 

9. GDP INTEL 432/601 MF=006 REV H S/N=xp=-000104 

10.GDP INTEL 11/16/82 432/601 MFe005 REV F 
S/Nexp#9000095 MDe17#0003 

delics 

12,IP.2LINK INTEL 432/603 172028004 REV & 
S/N#=xp-000+227 
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APPENDIX B 


OPERATING SYSTEM MODIFICATIONS 


The £L1MAX#432 operatina system supplied with the 432/670 
was not compatible with the hardware confliaquration, 
Specifically, interface processors are not yet supported, 
even though the 1MAX#432 operating system is confiqured for 
them. This necessitated a change to the ADA package body 
that describes the system processor configuration. The name 
of tnis vackage is PSORS.MBS. The code referring to the 
number of orocessors and interface processors in the package 
body PSORS.MBS must be changed to reflect the current 
physical state of the 432/670 system, For a three GDP poard 
confiauration with no IPL boards, the PSORS,MBS vould 
include the following descriptions: 

e= Define GDP boards present 

package osori is new GDPIDef(psoronum = 

packace osor2 is new GDPIDef(osorunum = 

package psor3 is new GDPiDef(psorunum => 
processori!: processor retyoes psori.osor;: 

Processor2: processor retypes psor2.osor; 


processor3: orocessor retyoes psor3,.psor; 
ee Define emoty slots 


processor3: constant processor !:= null: 
processor4: constant processor := null: 
processors: constant processor := null: 


A complete discussion as to now these changes can  0be 
incorporated in the PSORS.MBS package can be found in 


Reference 7, 
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APPENDIX C 


ADA SOURCE CODE 


All of the benchmark programs that were coded in ADA 
follow. Most proarams are composed of three parts, That is, 
a package specification, package body, and a driver or main 
routine, Tne respective voarts are labeled accordingly. The 
Orograms obtained from U.C. Berkeley are composed of just a 
single main routine, For easy cross reference the program 
name and the corresponding benchmark program are listed 


below, 


proaqram name| program description 


CHARSI : Character search with procedure 
overnead, 

CHARSZ ¢ Character search without procedure 
overnead, 

QUICK! s Quiecksort iterative 

QUICK2 ¢s Quicksort reeursive 

HASH ¢ Hash funetion 

DCOM1 ¢ Diaqital Communication with procedure 
overhead, 

DCOM2 s Digital Communications without procedure 
overnead, 

MEM1 s Recursive memory test 

MEM2 s Iterative memory test 

SEARCH > U.C. Serkeley character search 

SIEVE : U.C. Berkeley orime number generator 


ACKER 


U.C. Berkeley Ackerman’s f£unetion 
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In addition to the programs above , two otner programs were 
coded in ADA but were not executed due to compiler 
limitations. The RungesKutta inteaqration was coded and the 
source code appears under the program name RUNGE, Some of 
the orograms were extensively tested under = an ADA=ED 
interoreter, The linked list insertion program was written 
and tested in ADA#ED and the source code for it is under the 
program name LINK, The reader is warned that these two 
programs, RUNGE and LINK have NOT been tested under ADA#432 
and some modifications may be necessary to get them to 


execute, 
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“- CHARS! package soecification 


-- This is the ADA specification oackage for the 
-- CFA character Search benchmark. 


@-- CHARS 1 


package SCHAR is 
Subtype Subint is integer ranqe 1..256; 
vio stxtarcay 1S array(l..c56) of character; 
arraylrvarraye : txtarrav, 
Orocedure ROFIL; 
DSrocedure SEARCH(srchlen,aralen : IN subint; 
arrayvl,arraye : IN txtarray, 
loc : OUT subint); 
end SCHAR; 
“= CHARS1 package odody 


orfragqma environment ("ACSSTEXTIO.MLE","INTIO.MSE", 
PSChAR MSE") 3 
with text€ios,intios use texttior,intiorasciis 
oackage body SCHAR is 
Srocedure RDFIL is 
lineeofeinout =: string&d; 
emar ;s; character; 
ivi &$ integer; 
begin 
skioeline; 
neweline(); 
outelinee30( "Enter Srchestrna, $ endsecceoee”)? 
is:=1; 
ji=13 
while 1 < 256 looo 
lineeofeinout 3:= Getelinee&0(); 
exit when lineteofeinout(l1) = 'S'; 
nore} 4M 1.2.80 looo 
exit when lineecofeinout(j) = ' ' and 
lineeofeinout(j+tl) = ' '3 
array!(j) := lineeofeinput(j)? 
Y = Y*17 
end looo; 
end looo; 


-- fill array 2 
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neweline(); 


outelinee30("Enter Srchr-ara,r, $ endScceccervee dz 


i 3= i, 
while i < 256 loop 
lineeoftinout 3:= Getelinee80(); 


exit when linetcofeinout(l) = 'S'; 

for j in 1.280 top 

exit when linetofeinout(j) = * ° and 
lineeofeinout(j+t) = ° 83 


arraye(j) t= lineeofeinout(j): 
1 3:3 j+1, 

and tooo, 

end looo,; 


“-- check the array'’s contents 


neweline(); 
forey ify 1.-00 looo 
outCarrayl(i)); 
end looo; 
neweline(); 
mor 1 in 1.30 tooo 
out Carrayce(i)); 
end loop; 
outelineel1IN( "end ROFIL "); 
end ROFIL;? 
OrPocedure SEARCH(srchlien,aralen 
arrayl-rarraye 


IN inteqer, 
IN txtarray?; 


loc OUT inteaer) 

iyj 3 Integer? 
beain 

wes = il; 

foes = ls 

loc := el; 

while i <= srchlien loop 

if arrayl(i) = array2e(j) then 
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end SEARCH; 
end SCHAR; 


CHARS! driver routine 


Ofagqma environment ("ACS:TEXTIO.MLE","INTIO.MSE","SCHAR.MSE", 
BPMAINSMSE™) > 
with textfio,s,intiorsschars use texteiorintiosscharsasciis 


“- ROFIL and SEARCH contained in the same voackage 


-- Timing also includes time for orocedure 
-- Ynviecat ion. 


oackage body USERePROCESS€1 is 

Procedure MAIN is 
i,locr,srchelenaths,srchearartimerelooop 3: inteaer, 
forever : boolean :=true; 
answer : character; 


beaqin 


while forever looo 
-=- initialize the arrays 


for i in 1..256 looo 
arrayl(i) ° 
arrayeli) : 
end looo; 


== get the search arguments 


ep 
=> 
=e Re 


neweline(); 
Sutesv@ Character search Q=Quits...e..")} 
aetlCanswer): 
exit when answer ='Q'; 
Rr 1 tay 
neweline(); ; 
pute SOC"Lenath of string to search?..."); 
get(srchelenath); 
neweline(); 
puteS0( "Length of string to search for"); 
get(srcheargq); 
neweline(); | | 
Stes cesumoer Of 1OODS EO times«cocces")3 


Be 





get(timereloon); 
neweline(); ; 
outecdO(" Start of Search....")3 
put (BEL); 
for i in lee timere¢looo looo 
SEARCH(srchelenath,srchtarg,arrayl,arraye,loc); 
end loop, 
out (BEL); 
neweline(); 
putecO("*end the search... J)? 
neweline(); 
putelO("Location= "); 
out (loc); 
Skiotline? 

end looo0; 

end MAIN; 

end USERePROCESSe1; 
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== CHARS2 package specification 


package SCHAR is 
type txtarray is array(l..256) of character; 
arrayl,arraye : txtarray: 
procedure RDFIL; 
procedure SEARCH(srchlen,arglen 
arrayl,arraye 


IN tnteger;, 
IN txtarray? 


loc OUT inteaer); 
end SCHAR; 
-- CHARSe ovackage body 
-- Timing promots in the body of the search orocedure 


pragma environment ("ACS TEXTIO.MLE","INTIO.MSE", 
OCH AR eMOoE® )s 
with texttior,intios use textetior,intiosascii; 
package body SCHAR is 
Orocedure RDFIL is 
lineeofeinout $3: string80; 
char : character; 
i,j : integer; 
bean 
skipeline; 
neweline(); 
pute¢lineeS0("Enter Srchestrnar, $ ends.cccoce”)2 
j,2:=1; 
josie 
while i < 256 loop 
linetofeinout = Getelinee80(); 
exit when linetofeinout(i) = 'S'; 
for j in 1t..80 looo 
exit when linetecofeinout(j) = ' ' and 
lineeofeinout(jti) = ' '3 
arrayi(i) = lineeofeinout (j)>3 
+ s= +17 
end looo; 
end looo; 


-- fill array 2 
neweline()? 
outelineeS0("*Enter Srchmwara, S$ endsecccccee”)3 


7 s= 1; 


while i < 256 looo 
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lineeofeinout := Getelinee80(); 
exit when lineeofeinoput(l) = '5'; 
Pop fin lo n0 100 
exit when linetcofeinput(j) = * * and 
linetofeinout(j+!) = °' '; 
array2(i) 3:= linetofeinoput (j)7 
1 3= yl? 
end looo; 
end loon; 


-- check the array's contents 


end ROFIL; 


procedure SEARCH(srchlensarglen : IN integer; 
arrayl,arrave : IN txtarray; 

loc : OUT integer) 
i,irsks,/timerf¢loop 3: integer; 
begin 

neweline(); ; 

outeSd( "Number of loons to timececcece Jz 
get(timereloon); 

neweline()-; 

surecO (Start of search.....")? 

out (BEL); 


-1; 
while + <= srechlen loop 
if arrayi(i) = arrayel(j) then 
1f j+1 <= arglen then 
1 #33 vel; 
j 3= ji; 
else 
loc $= i2*)?3 


end if; 

end loon; 

end loop, 

out (BEL); 

outecd("end the search....-.")7 
neweline(); 


S= 


1S 





end SEARCH; 
end SCHAR; 
-- CHARS2 driver routine 


Pragma environment ("ACSSTEXTIO.MLE","INTIO.MSE","SCHAR.MSE", 
| "MAIN.MSE")? 
with texttio,intio,schars use textelios,intios,schar,ascils 


-- RDFIL and SEARCH contained in the same package 
-- Timina 1s for the SEARCH only. Promots are from 
-- the SEARCH orocedure 

-- reset. -196ic 


package body USERePROCESSe€!1 is 
Orocedure MAIN is 
i,plocesrchelength,srchtarg 3: integer; 
forever : boolean s:=true; 
answer : character, 


begin 


putes0("charse with 4 ado confiaurat.e.")? 
neweline()?; 


while forever looo 
-=- initialize the arrays 
arrayli(i) oy 


arrayve(i) 
end looo; 


for i in 1..256 loop 


¢ ¢t « 
e 


== get the search arguments 


neweline(); 
pists ("Character search G=Quits......")7 
get lCanswer),; 
exit when answer ='Q'; 
ROFIL; 
neweline(); ; 
pute©S50("*Lenath of string to search?..."); 
get(srchelength); 
neweline(); 
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putes0(“Length of strina to search for")? 
get(srcheara); 
neweline(); 
SEARCH(srchelenath,srcht¢ara,arrayl,array2,loc); 
outelOC*Location= "); 
put (loc); 
Skipeline; 
end loop; 
end MAIN; 
end USERePROCESS€e1; 
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--QUICKI Oackage svecification 
-- QUICKSORT package specification (Iterative) 


package QUICKSORT is 
type item 1s 
record 
key : Integer, 
data : character; 
end record: ; 
tyoe inarray is array(1..29) of item, 


Procedure SORT(Carg : IN OUT inarray); 


end QUICKSORT; 


\e- QUuIcKi package body 
“-- QUICKSORT oackage body (Iterative) 


oragma environment ("ACS:TEXTIO.MLE",*INTIO.MSE", 
"QUICK MSE"); 
with text¢io,intior,quicksorts 
uSe textfeiors,intio,quicksort, 
package body QUICKSORT is 
Srocedure SORT(Carg : IN OUT inarray) is 
m : constant := 20; 
ivjrler & integer; 
mideot,ytemp =: item; 
tyoe stackeframe is 
record 
ler 3 integer; 
end record: : . 
Stack : array(i..m) of stackeframe; 
S$ = Inteaer,s 


Beain 
r s= {3 
r 3= 203 
gs $= 13 
stack(1).1) s= 17 
stack(1).r := 20; 
looo 


} s= stack(s).J7 


88 





tack(s).r7 
- | 


s= argl(( ler) le); 


while arali).key < mideot.key 


{f= 1 +13 
end looo; 


while mideot.key < aralj).key 


joss jet: 

end lo0o0o0,; 

if 1 <= j then 
temo := arg(i); 


=e 


exit when ji > j 
end loop; 
if i < pr then 
s $= sel; 
stack(s).1 3 
stack(s).r 3 
end if; 
rp $= je 
exit when | > 
end loop; 
exjt when s = 0; 
end looo; 
end SORT; 
end QUICKSORT; 


—h 
=e 6 


Te 
+ 


“= QUICK} driver routine 


loop 


loop 


-- QUICKSORT package body for Oriver (Iterative) 


ofagma environment ("ACSSTEXTIO.MLE*, "QUICK.MSE", 
ST NTT OSM See” » “MATIN IMSE *) > 


“with quicksort,textetios,intios 


use quicksort,texteio,intio,ascii; 
package body USERePROCESS€¢1 is 


Orocedure MAIN is 
aragrtempearray $: inarray?; 





i, loopeval,} 3: integer; 
data : boolean := true; 


Begin 
for i in 1.20 loos 
argli)d.key 3:= 0; 
argli).data := 'a'; 


end loop, 


neweline(); 
outelineeeO("QUICKSORT BENCHMARK "“)?3 
outelineecO0("Iterative Version...")3 
outecd("Enter key, foilowed "); 
outecd("immediately ov data,"); 
outelineec0(" 0 terninatesS..c.ceee Je 
neweline()? 
ij 3= tt; 
while data looo 
getlarglid.key); 
exit when argli).key = 0; 
skip¢lines 
get(ara(j).data); 
ieee 1 +17 
skiof¢line; 
end looo,; 
neweline(); 
outelineelOC"Your Inout"); 
fom.) in 1..20 Jooo 
outl(arali).key), 
outlaragl(i).data), 
neweline(); 
end looo; 
Loop ; 
puteSdO("*Number of loops to time..cece.")3 
get (Cloooeval); 
exit when (loooeval) = O07 
neweline(); 
for 1 in 1..-20 looo 
temofarrayl(i)d.key $= argli).key; 
tempearray(1).data := arali).data:; 
end looo; 
outecdO("Start of Quicksort..");3 
out(del); 
more 1 in i.e-(loonoeval) looo 
mor j im t.-20 looo 
arg(j).key := tenotarrayl(j). kev; 
arg(j).data := temoptearray(j).data; 
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end loop; 
SORT (arg)? 
end looo,; 
out (bel); 
neweline(); 
outelinee#20("End the Quicksort...")7 
outelinee!OC"*The Output"); 
for 1 in t..-2c9 loon 
out (Caraqli).key); 
put Carol(:).data); 
neweline(); 
end looor 
end Looo; 
end MAIN, 
end USERePROCESS€1; 
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e- QUICK2 package specification 


“= QUICKSORT package specification (Recursive) 


package QUICKSORT is 
tvoe item 1s 
record 
key - integer, 
data : character; 
end record; ; 
tyoe inarray is array(!..20) of item; 
Subtyoe subint is integer ranae !1..c0; 
Orocedure SORT(Cleft,right 
ara 


mM SubiIiNnt? 
in out Inarray); 


end QUICKSORT,; 


e- QUICKe package body 


\“- QUICKSORT opackage body (Recursive) 
Oragma environment ("ACS3TEXTIO.MLE","INTIO.MSE", 
SOU TCK.MSE™) 3 
with text¢io,s,intio,quicksorts use texteior,intio,aquicksort; 
package body QUICKSORT is 
Orocedure SORT(Cleftrriqht : in subint; 
arg > in out inarray) is 
Yej 2 SUbINt? 
mid@#ot,temo 3: item; 
Begin 
1 $= left; 
j} 3= right; 
mideot := argl(lefttriaqht)/2); 
Tooo 
while argli).key < mideot.key loop 
1 3= 1+17 
end looo; 
while midept.key < ara(j).key looo 
j 33 jel; 
end 0007 
if 7 <= j then 
temo s= aral(i); 
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we se 44) Ut 


exit when 1 > j3 
end loop? 
if left < j then 
SORTCleft,j,arg); 
end if? 
if 1 < fight then 
SORTCi,right,ara)? 
end if; 
end SORT; 
end QUICKSORT; 


--QUICKe driver routine 
-- QUICKSORT oackage body for Driver (Recursive) 
Oragma environment ("ACS:TEXTIO.MLE","QUICK MSE", 
MENTEOVMSE™, "MAINRMISE” ) 7 
with quicksort,texttrorintiosz 
use aquicksort,texteiaos,intio,ascii; 
package body USERePROCESSe! is 
Orocedure MAIN is 
arqg,temoearfray $3: inarray; 
lefteindex,riahteindex : subint;s 
1,looceval,j 2? integer; 
data : boolean := true; 
Beain 
moe 1 im 1..20 looo 
e@ralid.key 3:= 07 
argli).data := ‘a 
end loop; 


te 
g 


neweline(); 

outelineec?O("QUICKSORT BENCHMARK "); 
pute cdO("Enter keys followed "); 
outecd("immediately by data,"); 
outelinee20("* 0 terminates.ccceee")? 
neweline(); 

m:c= 1; 

while data loop 
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getl(argli)d.key); 
exit when arali).key = 0; 
skioeline; 
get(arg(i).data); 
i ¢= y+41; 
skioteline?: 
end loop, 
neweline()3 
outelinet10(*Your Inout"); 
Hoe 1 In 1e-290 Jlooo 
putC(argl(i)d.key); 
outl(arg(i).data); 
neweline(); 
end looo; 
Loop ; 
out©30("# of looos to time?..9 exits "); 
get (Cloooeval); 
exit when (loooveval) = 0; 
neweline(); 
for i in 1.2.20 looo 
temoearrayli).key := araqli).key; 
tempearrayl(i).data := arali).data; 
end looo; ; 
putecd("Start of Quicksort..")7 
out(bel); 
for 1 in 1..(looneval) loon 
fon} im t..c0 loooe 
arg(j).key 3:= temoearraylj).key; 
arg(j).edata := temotarray(j).data?> 
end looo; 
lefteindex := 
riqhte€index := 
SORT (lefteindex 
end looo-; 
out(bel); 
neweline(); 
outelineecO("End the Quicksort..."); 
outelineetlO("*The Outout"); 
gore in 1.2c0 1000 
put (argl(i).key); 
Sut Cardq(;1).data); 
neweline(); 
end loop; 
neweline(); 
end Loop; 
end MAIN; 
end USERePROCESS€1; 


1; 
20; 
rriaqhteindex,ara); 
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-- HASHL package specification 


package HASH is 

Size °: integer s= 10; 

table : array(0..9) of integer; 

function HASHES(key : IN integer) return integer; 
end HASH; 


©-- HASH! obvackacge body 
Pragma environment ("ACS TEXTIO.MLE”","INTIO.MSE","HASH.MSE"); 
with textfio,intio,s 
use textelo,intio,ascil; 
package body HASH is 

function HASHES(key : IN inteaer) return integer is 

check,i $$ integer; 

Begin : 
== comoute the first olace to look 

check := key mod size; 
for i in 1..size/2e looo 
if table(check) = key or table(check) = 0 


then 
return cneck; 
else 
check := (checkti) mod size; 
end if; 


end loop; 
return 0; 
end HASHES; 


end HASH; 

“- HASH1 driver routine 

-- hash table search benchmark 

-- hashl.eod on disk 

-- timing includes orocedure invocation overhead 


oragma environment ("ACSSTEXTIO.MLE"*,"INTIO.MSE","HASH.MSE", 
“aN oMSEM); 

with text¢io,s,intio,HASH; 

use textte¢io,intio,-HASH,ascii; 


a5 





package body usereprocessel is 
procedure main is 
timerelooo,positionskeysjy 3: integer; 


answer > character; 
forever > boolean := true; 
begin 


neweline(); 
SsuceeoC"*HASH!] benchmark.....")? 


-- fill the hash table with CFA samole entries 


table(0) s:= 07 
table(1!) := 183, 
table(e) 3:= 113 
taodle(3) := 1035; 
table(4) := 1035; 
table(S) := 183; 
table(6) := 86; 
table(7) := 0; 
table(8) := 183; 
table(9) := 183; 


while forever looo 


neweline(); 

putecd0("Continue? Q: quits."); 
get lanswer); 

exit when answer = ‘'Q'; 


neweline(); 
putecd0("enter an integer key"); 
get(key); 


neweline(); 
outeS0(*number of loons to timecececee”)2 
aet(timereloono); 


neweline(); 
putecdO ("start hash lookunp...")3 
out(bel),; 


for j in leetimereloono looo 


position := HASHES (key); 
end loop; 
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out (bel); 

neweline(); — 

oputeced0("end of hash lookup..")3 
neweline(); 

puteed("hash oosition = ceee")i 
out(position); 

skioeline; 


end loop; 
neweline()?; 
meee end of HASH tanple licokUuD..sece”)? 


end main; 
end userteoprocessel; 


OF 





-=- DCOM1 package specification 
-- Digital) Communication Processing Program 


-- i9 Oct 82 
Oraama environment ("ACS:TEXTIO.MLE"); 
with text€io 7 use texteio; 
Package DIGeCOQM is 
ei. constane $= 10; 
ce : constant s:= 10; 
Ssubtvoe cesttetyoe is Integer range 1..ct? 
Subtyoe contidetyoe 1s Inteaer range 1..c2; 
tyoe message, 
tyoe messagqetotr 1s access message, 
type message 1s 
record 
destination 
connection 
size 
data 
end record, 
subtype buftindex is integer ranae 1..c2;7 
Byee Sufetb! is array(i..ce) of bufeindex; 
tyoe bufetblieotr is access bufetb]; 
Seserinationeth!) * array(!..c!l) of bufetbleotr; 
Guerre rearray = artayli..ce) of strings); 


destetyoe; 
coneidetyoe; 
Inteaer; 
string30; 


orocedure forward(msa: IN messageenotr); 


end DIG«COM; 


-- DCOM1 package body 


eeargma environment (“ACS:TEXTIO.MLE*,"DCOM.MSE",”"INTIO.MSE"); 
with text¢iorv,intio - use texttior,intiors,ascii; 


package body DIG¢eCOM is 
procedure forward(msq : IN messagqeeotr) is 
ivj 3 integer; ; 
buffereindex : buftindex? 
line $: oufetbleotr; 
bufearray 3: bufetd}; 
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begin 
line s= destinationetol (msq.destination); 
buffarray s:= line.all; 
i:=1; } 
while buftearray(i) /= msa.connection looo 
is= itl; 
end loop; 
buffereindex := bufearrayli) 
bufferearray(buffereindex) °: 
end forward; 
end DIGeCOM,; 


, 
= msQq.data,; 


-- OCOM1 driver routine 


-- digital communication benchmark 


-- DCOM12.E0D on disk 
== timing includes orocedure invocation overhead 
-- €e6 Oct 1982 


pragma environment ("ACSI TEXTIO.MLE”",.”"INTIO.MSE”","DCOM.MSE", 
weap Moe” ) > 

with texteio,intio, DIGeCOM; 
use textt¢io,intio,DIGeCOM,ascili; 
package body usereprocessel 15 
procedure main 15 

irvjJ 3 Integer; 

timer¢looo : integer; 

k >: buffindex; _ 

oufetableeotr $: oufetblenotr; 

mSQeout =: messaqetotr, 

forever : boolean := true; 

answer : character, 


begin 
outeS0("charstx. 4 gdo confiauration...")} 


neweline()7 

oute SOC "timing includes proc ovhd.ccee”)? 
-“- initialize the destination table 

neweline(); 
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outes0("init destination table........")s 
foOrmieth leecl 1coo an 
destinationetb!] (i) %:= new bufetbl, 

end looo; 


-- jnitialize all bufetbl's 


neweline(); ; 
pute sOC"init buffet bd] "Seceeeeecccceeeee IF 
for win i.-¢!i looo 
oufetableeotr 3:= destinationetol (i); 
for} in 1|.-¢e 1900 
buft¢tableentr(j) 3: j-> 
end looo,; 
end loop, 


== jnitialize buffer 


neweline(); 
BuceeO ("init the buf fer... 2. ")? 
form kK in t.-ece loons 
PPPOE ACICAY CK Ens = cos ccceccccc we cee eos eee ecw eeecce # 
end looo; 
neweline(); 
while forever loco 
outelO("continue? "J; 
set(Canswer); 
exit when answer ='N'; 
msgqeout <s= new messaqge,s 
mSQeout.size := Q; 
neweline(); 
outecOdO("start digit comm...."); 
neweline(); 
outes0("enter destinations connrdata..")? 
get (msqeout.destination); 
skipe¢lines 
get (msgeout.connection); 
skipte¢line; 
mSQ*out.data s=aettlinee30(); 
neweline(); 
pute©S0("number of loons to time.ccecee”)? 
get(timereloon), 
pute ld("sending...")2 
out (bel), 
for 1 in te-timere¢loop looo 
forward(msgteout); 
end loop; 
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out(beld; 
BUieoeUt jf eadone SENdING...2.")7 
neweline(); | 
parecuC buffec flush is.....')? 
HOGek Im i..<¢e }000 
put (k); 
putelinee+30 (buf ferearray(k)); 
neweline(); 
end loop; 
skioelines 
end looo; 
neweline(); 
emer oC end of ceconl..eceee’)? 
end main; 
end usereorocessel,; 





-- DCOMe package soecification 
-- Digital Communication Processing Program 


“-- 19 Oct 82 
pfagma environment ("ACS :TEXTIO.MLE"); 
with texteio 7 use texteio; 
Package DIGeCOM is 
@l s; e€onstant := 10; 
€2e : constant : 10; 
Subtyoe destetyoe is Integer ranqe {t..c1; 
subtyoe contiattyse 15 integer range !..¢2; 
tyoe messaaqae, 
tyoe messaaqeentr 1S access message; 
type messaqe 1s 
record 
destination 
eoanect ion 
$size 
data 
end record; 
Subtype bufeindex 18 integer range 1..ce; 
myoe bufetb!} is array(i..c¢d) of oufeindesx; 
tyoe oufetoleotr 18 access bufetol, 
Meemimationetb! = array(l..cl) of Gufetblenptr:? 
bufferearray : array(i..ce2) of string30; 


destetyoe; 
conteidetyoe; 
integer; 
string50; 


e@ ee o8 ee 


MProcedure forward(msq: IN messageeotr); 


end DIG¢COM; 


memo cCOMC package’ body 


Seeeome environment ("4CSSTEXTIO.MLE”,"OCOM.MSE","INTIO.YSE"); 
with text¢io,intio ¢- use texttios,intio,ascii; 


package body DIG*COM is 
Procedure forward(nmsq : IN nessaaqeeotr) is 
ivyjJ 3 integer; 
timere€looo 3: integer; 
buffereindex 3: oufeindex; 
meme : outéetoleotr; 
Bumearray : bufetol!; 


ie 





begin 


neweline(); ; 

rie NUmperLOf 1OODS tO timeseccecee )? 

get(timert#loon); 

SuteloO@o sending... )7 

put (bel); 

Honmieinm leetimer¢looo tooo 
line t= destinationetbl (msg.destination); 
bufearray := line.all; 
is=1; 
while bufearray(i) /= msa.connection loon 

je= ¥+1;7 

end looo; 
bufferteindex := buftearray(i) 
buffertecarraylouffereindex) 3: 

end loop; 

out(bel); 

meee OC” ...done SENdIingeccee’)? 

neweline()?3 

end forward: 

end DIG+COM; 


; 
= msg.data, 


e- OCGMe2 driver routine 


Semeeeaigital communication benchmark 


-- Deer2eleeeo on disk 
—_ timing does not include procedure invocation overhead 
-- Bemoct |o982 


meaamea environment (™ACS:TEXTIO.MLE”","*INTIO.MSE”,"DCOM.MSE”, 
aMeathsMse”); 
with texttio,intior DIGeCOM; 
use texteio,intio,DIGeCOM,ascii; 
package body usereorocessel is 
procedure main 1s 
iv} 3 integer; 
ke > ouff€index,; 
bufetadlefeotr : bufetbleotr: 
ogee Out +» nessagqetotr; 
forever : boolean := trues 
answer : character; 
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begin | 
pee oOG@aenarse. 4 900 Configuration..." )?7 


neweline(); 

SUuresot timing does mot include oroc.."); 
“= jnitialize the destination table 

neweline()? 


pute s0("init destination tablews.ceeee' Ji 
mari im lLeeCtl 1000 

destinationetbl (i) $= new bufetol, 

end looo; 


“== jnitialize al} bufetb)'s 


neweline(); 
Bee OCT INIt SDUFEED] Sec cesvcccoeceseee I} 
morsi in 1l.-ecl looo | 
bufetableeotr 2= destinationetho) (i); 
mor y tm lee¢ce loon 
bufttableeotr(j) 3= j-; 
end looo; 
end loop, 


== initialize buffer 

neweline(); 

Meee oC init the buffer.ceceee J? 

foes in 1.ece ooo 

SE VCC) = 6 6 sis eo elee 6 ce eo ee ee ce eee weer ee F 

end loon; 

neweline(); 

while forever J]oo0o 
eeteld{("*continue?: “); 
getlanswer); 
exit when answer ='n'!; 
nsgeout s= new messaqae, 
nmSgQeout.size := 0; 
neweline(); 
emcecO("start digit comm....")? 
neweline(); 
putesd0( "enter destination, conn,data..");3 
get(nsgeout.destination); 
skioe€line; 
get(msgqeout.connection):; 
skioeline; 
NSQeout.data !=aetelinee30(); 
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forward(msgtout)? 
outeed("buffer flush iSeeeee' J)? 
wot ek elny iseCe |OOO 
Bu a6 ki.) : 
putelinee30 (buf ferearray(k)); 
neweline(); 
end loop; 
skioteline; 
end looo; 
neweline();s — 
eeeeecO("end of decomi.wccsee”)? 
end main; 
end usertorocessel; 


> 





e- WVEMI package soecification 
-- WEM1 recurSive memory test sackage specification 
pPfagma environment ("ACS TEXTIO.MLE"); 
with text€io; use textteio; 
package EAT*MEMORY 1s 
$ize : constant := 50; 
: Integer 3:=07 
tyoe smalletable is array(1..s1z2e) of character; 
type smalletableteotr 1s access small¢table; 
procedure FOREVER; 
end EATeMEMORY; 


--MEM] package body 
-- MEM] recursive nemory test body 


omaama environment ("ACS:TEXTIO.MLE","EAT.MSE","INTIO.MSE”) >; 
with intio,texteio;, 
use Intio,texteio; 
package body EATeMEMORY is 
procedure FOREVER is 
tableftotr : smalletableeptr;, 


neweline(); 
tadleeoptr := new smalletable,; 
FOREVER; 
end FOREVER; 
end EATeMEMORY; 


7-2 MEM Griver routine 
“= MEM! recursive memory test driver routine 


mmaama environment (™ACS:TEXTIO.MLE","EAT.MSE", 
“MAIN.MSE*™)? 

with texte&io,EATeMEMORY; 

use texteio,EATeXEMORY; 

package body usertorocessel! is 
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procedure main 1s 


begin 


pute 50(" Start of eat MMINOMLY sere «se ee oe. 
FOREVER; 
end main; 


end usereorocessel; 
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-=- MEM2 package specification 
-=- MEM2 interative memory test vackage svecification 


praama environment ("ACSSTEXTIO.MLE"); 

with textf€ios; use texteio; 

package EATeMEMORY is 
$size 3 constant 3:= 50; 
i: Integer 3=0; 
type smalletable is array(1..size) of character; 
tyoe smalletableetotr 18 access small¢etable; 
procedure FOREVER; 

end EATeMEMORY; 


@-=- YUVEM2 package body 


-~ MEM2 interative memory test body 
pmagma environment ("ACS:TEXTIO.MLE","EAT.MSE*,"INTIO.MSE"); 
with intiortext¢io; 
use INntiorstexteio; 
package body EATe&MEMORY is 
procedure FOREVER is 
tabletotr : smalletableeotr; 
infinite > boolean s=true; 
begin — 
while infinite looo,; 
1 3s= 141; 
put(i); 
neweline(); 
tablefotr := new smalletable; 
end looo; 
end FOREVER; 
end EATeMEMORY; 


~- YEMOQ driver routine 
-- WVEM2 interative nemory test driver routine 
oragma environment (7ACS:TEXTIO.MLE","EAT MSE", 


aM Nee SE” ) 
with texteio,EATeMEMORY; 
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use texteior,EATeMEMORY; 
package body usereprocessel 15 
procedure main is 


begin 


Smee a0" start of eat Memoryecceccecee IF 
FOREVER; 
end main; 


end usereorocessel; 
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== SEARCH 


-- Courtesy Prof. Patterson,Comouter Science Division, 
-- Department of Electrical Engineering & Comouter Sciences, 
-- Univ. of Caiifornia, Berkeley,CA, 
oeragma environment ("ACS:TEXTIO-MLE","INTIO.MSE","MAIN.MSE"); 
with texteio,intio, 
use texteior,intios,ascil: 
package body USERePROCESS+¢1 is 
Oorocedure MAIN is 
tyoe strin is arraylintegqer range 1..i120) of character; 
mumiterations $: integer; 
DOSItTIONs,NSszNK 3: integer; 
Ss, 7 oS erin: 
function STRSCH(s,k 


>: IN strin; 
ASenem 3 


IN integer) return integer 1s 
Vee Si nteoger; 

base,ksave,cont : integer; 

kend,ssave : integer; 

r 3 integer; 


while s(€i) /= k(€j) looo 
if 1 >= cont then 
a sae! 
goto finish; 
end if; 
1 3s= yl; 
end looo; 
ssave := ji; 
ie c=) tls 
while j <= kend loop 
les = iti; 
ieeest i) y= kt ;) then 
1 ¢= ssave + 1; 
} 3= ksave, 
goto too, 
end if; 
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| cose jel; 
end 1000; 
r $= ssave = base + 1; 
<<finish>> 
return (r); 
end STRSCH; 


Begin 


s(1..60) := "o00000000000000000000000000000000000 
Jgoo000000000000000000000"; 

mioie.te0) 2= “he xe COO000000000000000000000000HERE 
IS A MATCHOOOOOOOCCO00000"; 

Meine cO) := “HERE IS AtMATCH 


me@ole.1cO) <= * 


}ooo 
putelinet30("Berkeley Character Search Bi) 
pute30("4% of looos to time?..0 Exits "); 
gGet(numiterations); 

exit when numiterations = 0; 

newtline(); 


ms 3s= 120; 
fins = 15, 
outl(bel); 


for i in 1leenuniterations looo 
Sesition <= SIRSCH(s,k,ns;nk); 
end looo, 
put(bel); 
putelineelOC"™END SEARCH"); 
put (position); 
end loop; 


end MAIN; 
end USERePROCESS¢€1; 


a) 





SUE VE 


Courtesy Prof. Patterson, 
Department of Electrical 
University of California, 


pragma environment ("ACS:3 TEXT 


Computer Science Division 
Engineering & Computer Sciences 
Berkeley CA, 


IO.MLE","INTIO.MSE", 


"MAIN. MSE"); 


with textf¢io,intio; 
use texteio,intio,ascii?z 
package body USERePROCESSe! 
Orocedure MAIN is 
size s; constéent integer :; 
maas : array(0..size) of 
Orime,s,krscount,loopeval 3: 1 


Begin 
1000 | 
Bute s0("#F of loons to ti 
get (loopeval); 


exit when l)oonteval = 07 
neweline(); 
put (bel); 
mor iter in 
count := 0, 
ror 1 In 0..Size loop 
figs (i) s= true; 
end loop, 
for i in 0..size loop 
mt fhaqgs(i) then 
prime 3:= i + i + 3; 
kK $= ij + prime, 
while k <= size loop 
fiags(k) := false; 
k $= k + orime; 
end loop, 
ecumt += count + I, 
end if; 
ead |oop? 
end loop, 


put(bel); 
putelinee10(" 
put (count); 


putei0(" Primes es 
neweline(); 
end looo; 

end MAIN; 


end USER¢PROCESSe1; 


inteaer range 1..(loonteval) ) 


End Sieve" 


1s 


C00; 
boolean; 
nteqer,; 


Ne 


me?..e.0 exits 


loop 


); 


ie 





-- ACKER 


-- Courtesy Prof. Patterson,Comouter Science Division, 
-- Department of Electrical Engineering & Comouter Sciences 
-- Unive of California, Berkeley,CA. 


pragma environment ("ACS:TEXTIO.MLE”","INTFIO.MSE”,"MAIN.LMSE"); 
with text€io,intios 
use textfio,intio,ascii: 
package body USERePROCESSe!1 is 
Oorocedure MAIN is 
ar,irsaraglrarg2 : integer; 
function ACKER(x,y 3: IN integer) return integer 1s 
begin 
if x = 0 then 
return (Cyt1); 
elsif y = 0 then 
return ACKER(x-1,1);3 


else 
return ACKER(x-1,ACKER(x,yeol)); 
end if; 
end; 
Begin 
putelineelO0("Ackermann Benchmark "); 
putelineeeO("To Exit, Enter 0 eyes 
putelineeS0(*Begin time when bell] sounds 3 
loonr 
outelinee3S0("Enter ACKER Aguments sae) ar 
get(argl); 
exit when argl = 0; 


skioeline; 
get(argqe); 
out(bel); 
a := ACKER(argql,arge); 
out (bel); 
poeeiO("Outout of "); 
outlarg!); 
Sue Cae 3 
sut(arge); 
neweline(); 
put(a); 
neweline(); 

end lo0o0o; 

end MAIN; 

end USERePROCESSe1; 





APPENDIX D 


CFA BENCHMARK ALGORITHMS 


Tne twelve benchmark program algorithm descriptions 
used in the first CFA study follow, A more detailed 


discussion of these can pe found in Reference 8, 


moe y | 6 LNTERRUPT KERNEL, FPCUR PRIORITY LEVELS 

The interrupt Kernel will be activated by an [I/0 
meer ruot with priority level 0,1,2 or 3 from one of four 
devices, Actual interrupt processing will be simulated by 
SBeunting the occurrences cf each type of Iinterruct, Higher 
level interrupts will be anple to preempt processing of lower 
Peearority interrupts. The interrupt handier must orovide for 
resumption of processing of the preempted lower level 
interrupt from the point of preemption. AS much processing 
Beepossible will be’ done witn higher oriority I/0 interrupts 


enabled, 


Ze I/0 INTERRUPT KERNEL, FIFO PROCESSING 

The interrupt kernel will be activated by an I/0 
mmcerrust from one of four devices which will be slaced {fn a 
eee s. CUPP for tirstein=first-out (FIFO) processing, 
Merwe: int@®rrupt processing will be simulated by counting 


the o¢currences of @acn type of interrupt. Space should be 





provided to handle at least ten queued interrupts at one 


time, 


3. INPUT/OUTPUT DEVICE HANDLER 

After an I/O request is issued by an application 
program, and after the executive queues an input control 
block, this test pregram is initiated and {ft performs the 
Bo owing actions: 

Poemeck ‘Soe tueeor tires tape drives If device is busy 
exit. If tne device is not operable branch to an 
error routine. If tne device is available, sat up 
and initiate the regquested transfer, 

2, Arter completion of the transfer, and a conse=- 
quent interrupt, tne device handler is reentered 


and the following processing is performed: 


a, storemsrstus intormation (device type ane 
roaenti fication). 


o, If transfer was unsuccessful, abort further 
processing, 


G¢. If 8 succeésstul tPansfer oecurred and all re- 
Guested transfers accomplisned then exit, 


Tne application procrams perform hnign level logical I/0 


calls that cause the queuing, 


4. FAST FOURIER TRANSFORM 
The following variables are used in the algorithm: 


Ns Tne numper of data points O<= N <= 2**156, 

Bee | CU VM@CCCOr.6UmRMOlding )«€©6htnhe@lhCUWNmUCUCUSAMDLES.6hlUaAasS)—6UGomplex 
numpers, 

A$ A vector holding the first N/2 powers of EXP(= 
2*pi*i*/N), 

wOrks AUxiliary working storade, 


Leo 





procedure FFT(N,X,W) 
GROUPS := 
do for PASS := 0 by steps of 1 until 
Log2(njel 
do for all ELEMENT such that 
0 <= element <= N/2 
Maenerate complex addend" 


WEXP 35 
if PASS > 0 
then WEXP s=(CELEMENT¥N)/2) / 
2**PASS) MOD (N/2) 
endeif 


L1£ WEXP <> 0 
then TEMP1 := XCELEMENT+N/2) * 
wCEXP) 
else TEMP1 s= X(ELEMENT+4#N/2) 
end if 
"generate 2 element entries 
in data vector" 
XI CELEMENT) := X(CELEMENT) ¢ 
TEMP I 
XL CELEMENT + N/2) $= XCELEMENT) = 
TEMP 1 
end=do 
if PASS < (log2(N) @# 1) 
then 
"execute perfect card shuffle 
on data vector" 
Po 3s 2**PASS 
GROUPS := GROUPS/?2 
ao ror all £ sven that 
Om<= | < GROUPS 
Gomror all J shenothat 
0 <= J -< P 
INDEX1 := 2*P¥I + J 
INDEX2 := P*¥YI #J 
AGINDSS1 t= X) CINDEX 2) 
XCINDEX1+P) s= X1CINDEX24N/2) 
endedo 
endedo 
else 
fo wer ai} Lf such that 9 <= I < N 
X= oe) ) 
eéndedo 
endif 
end=do 





S. CHARACTER SEARCH 


The variables used in this algorithm are: 


SRCHSTR TOPOL Cer cOmaastring Of enaracters 
to be searched, 

SRCHLNGTH $: lenath of that string. 

SRCHARG * poimuver Go @ String of characters, 

ARGLNGTH : length of that string, 

LOC : an integer return code, 

WORK : pointer to any needed storage, 


procedure CHARSRCH(SPCHSTR,SRCHLNGTH, 
SRCHARG, ARGLNGTH, LOC, WORK) 
integer I 


LOC := ji 
do for all I such that O<= I <2 SRCHLNGTH=<SRCHARG 
OF aUmMeit, LOC “<> =1 
if the substring of SRCHSTR from I to 
ItARGLNGTH=1 = SRCHARG 


Smmeet! TEST, SET, OR RESET 


The variables used are; 


F : Function code, i=test, 2= set, 32 reset, 
N ¢ Relative bit to be tested, 
Misr omcerete tigntiy oaexed pit strins. 


Teo mnecode indicating original bit status, 
WORKs Pointer to any needed work storage, 


Srocedure BITTESTCE,N,A1,RC,WORK) 
imceéger ABIT,?D 


ARIT := Al + N/(word length) 
D := N mod (Cword length) 


Peep en bLt abeedaressABIT = i 
ERemM REC 28 





16 F = 2 
Enem DO-ttepic at address ABIT := 1 
else if F = 3 
then D’th bit at address ABIT := 0 
endeié 
endeif 


7. RUNGE#KUTTA INTEGRATION 
This algorithm solves the differential equation F(t,y) = 
eve = dy/dt using a third order Runge= Kutta integration. 


Tne variables used ares: 


TG : Initial value ot T, single precision. 
YO ¢ Treelalsvaliwre os ©, single onecision. 
4 s Interval of integration, single orecision, 


TMAX!: Final value of T, single precision, 
YMAX3: Final value of VY returned, sinale precision, 


procedure RUNGEKUTTA(TO,YQ,TMAX,YMAX, WORK) 
real K1,K2,«3 


YMAXK 3= YO 


Ge ter Sak iets trom 10 inermented in steps of H 
Meet xf > ~«TMAX 


Ki ss H¥(CT+YMAX) 

K2 $= H¥(T + H/2 + Y © K1i/2) 

K3 := H *® (T + 3*¥H/4 + Y + 3*K2/4) 
YMAX s= YMAX + 2*®K1/9 ¢ K2/3 + 4*K3/9 


endedo 


8. LINKED LIST INSERTION 
This algorithm inserts an element into a doubly linked 
list. Variables used ares 


bee tece s FOinear tome 11St Control block 
COGealming > 
Hoa DeOinw@er to first node, 
Tato pOlneer to last node, 
NUMENTRIES : number of entries, 
NEWENTRY: pointer to new entry to be inserted, 
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procedure LISTINSERT(LISTCB,NEWENTRY ) 


"the notation POINTER.FIELD is used to access 4 
particular field of the structure ponted to by 
POINTER" 


pointer PRESENT 
4# LISTCR,NUMENTRIES = 0 
then "list is empty, so initialize" 


LISTCB.HEAD := LISTCB,TAIL 3:= NEWENTRY 
LISTCR.NUMENTRIES := 1 
NEWENTRY NEXT $= NEWENTRY.PREV s= 9 


else 
"Yist not emoty" 


PRESENT := LISTCB.HEAD 
LISTCB,NUMENTRIES := LISTCB,NUMENTRIES + 1 
"determine position of new entry" 
while NEW. KEY >= PRESENT,NEXT <> 0 do 
PRESENT := PRESENT.NEXT 
{f PRESENT.PREV = 9 and NEw, KEY < PRESENT,KEY 
then 
M"mnew list nead" 


bistes HEAD: 
NEw,PREV := 0 
PRESENT,PREV $= 
NEWNEXT 3= PRESENT 
else 
if NEW. KEY => PRESENT,KEY 
tnen 
yew Tist taf)” 


PRESENT.NEXT := LISTCB.TAIL := NEW 
NEWNEXT s= 0 
NEW,PREV := ® 
else 
"Insert in middle" 


NEW.NEXT := PRESENT 

NEW PREV $= PRESENT, PREV 
PRESENT,PREV s:= NEW 

"hack up and link with predecessor" 


PRESENT s:= NEW,PREV 
PRESENT.NEXT := NEW 
end=if 
endeif 
endeif 





9. QUICKSORT 
TNLS algorithm performs ab quicksort on an array of 


records, The variable used are; 


N ¢: The number of records to be sorted, 
M Integer oarameter specifying the changeover 
point between auicksort and a Simple insertion, 
REC : Pointer or the first element of the 
array to be sorted, 
WORK: pointer to any needed working storage. 


procedure QUICKSORT(N,REC,M,WORK) 
integer L,&®,1,J,K 
integer array STACK(0O3:2¥*£(N) 1] 
ehnaracter string V 


REC(N41] s:= f 
bits, if R= 
do forever 

I := Ls Js= Rei 3 V se RECCL) 
do forever 
QO {] te) iti until REC{I} => V end-do 
do JssdJei until REC(U] <= V endedo 
tte 3> 1 
then swao RECCI] with REC{J] 
else aoto endefirst 
end-ié 
end-do 
encdetirst: 
swap PEC{L] with REC{(J] 
tf both subfile sizes (JeL and ReJ) <= M 
then 
{f stack empty 
then goto @#nde-outer 
else poo L and R from stack 
end if 
else 
if smaller subfile size <= M 
then set L and R to lower and upper 
WeTi=es Of Warces "Suoti le 
else push lower and uppoer limits of 
Waro er sutftfiiewonto stack 
set §£ and R te limits of Smaller 
subfile 
endelf 
endeif 

endedo 

endeouter: 
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do for I from Nei to i in seps of i 
if REC(I) > RE{I+e1) then 
Voss RECCI)? J sere! 
do forever 
REC{Je1}] := REC(CJ)] 3 J ssJel 
1 REC({J?} => V then goto endelast end=i1f 
end=do 
endelast: AfJwi} 3= V 
endeif 
endedo 


Moe ASCII TO FLOATING POINT CONVERSION 


The following variables @re used in this algorithms 


N : Number of characters in the string, 
Al ¢ Agdiresseot the character strins. 
A2 : Address of floating coint number where the 


result will be placed, 


procedure AFP(N,A1,A2) 
integer NUMBER, POSITION 
real ReSULT SG DIVISOR 
hoolean ISNEGATIVE 


ISNEGATIVE := false 

POSITION := 9 

epee iret chmracter of Al is a sign character 
tnen 


Peston character is "=" 
then ISNEGATIVE s= true 
endeif 
POSITION :s i 
endeif 
NUMBER s= integer equivalent of characters 
POSITION to J=i of Al where 
etiamecter J of Al is "," 
RESULT := floating point equivalent of 
NUMBER 
" tne following two steps can be done in 
parallel {ff desired" 
NUMBER s:= integer aquivalent of characters Jel 
to N of Atl 
DIVISOR := floating @auivalent of 10**(NeJ) 


wee es Reon + (fleeting point @quivarent of 
NUMBER) / DIVISOR 


eel 





11. BOOLEAN MATRIX TRANSPOSE 
The following variables were used in this algorithm: 
Ai : Sointer to a word of storage, 
A2 : bit number within word Aj where 
the matrix begins, 
N ¢: Size of the boolean matrix, 
procedure BMT(N,A1L,A2) 
inteqer T,J 
hooleanmn &f1i:N,1:3N] beginning at bit A2 of word Al 
Go for all I and J such that (i<= J <= N) 
ano (ae) <=) 1 = i) 


swap 83(12,J) and 8(J,T) 
endedo 


12. VIRTUAL MEMORY SPACE EXCHANGE 
This algorithm performed a virtual] memory space exchange 
momouagy the use of a supervisor call, There are two 
eumeeions which must be orovided by the algorithn, 
1. CALL: saves enough information to restore the ene 
tipet state.of tne caller, 
2e RETURN: restores the anvironment active pefore 
the previous call, 
The sixteen benchmark programs written by the second CFA 
seay, Grouo "“f0l1llow, A complet® discussion of them can be 


found in reference 1, 


1. TERMINAL INPUT DRIVER 

Bis alaGorithm inputs ome line of ASCII characters from 
a terminal device, Ajeet eerubeurs should  edelete the 
character, A carriage return terminates the line, The 


Droaram need not be reentrant, 
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Aleoericewm: A SubprouUcIn@® TTYIN( BUFFER) initiates the 
transfer, It has a single reference parameter, the 
butter to coe filled, The buffer consists of: 


ADDRESS TERMADDR 


CHAPACTER CBUF(1:?] 

The butfer is assumed to be large enough for the 
Pine, the transf4r is started and the routine re- 
turns. The interrupt service routine collects the 
line in some machine dependent manner. The terminal 
interface is assumed to oe a minimal one, (it does 
the serialecarallel conversion). when a carriage re= 
turn is entered, tne terminal input is disconnected 
and a transfer to the buffer TERMADDR is made, 


Ze MESSAGE SUFFERING AND TRANSMISSION 
This algorithm queyves a message buffer and then 


transmits tne message over a GMa link in FIFO order, 


RECORD BUFRCADDRESS NEXT, ADDRESS TERMADOR, 
Pope Gers tZE,ENTEGER DATACI?SIZE)); 
Pemeeien BUFR END, START 
ADDRESS TEMP; 
fQUEVE SUBROUTINE 
PeOCkDURS QUEVUECREFERENCE BSUFFER)= 
BEGIN 
IF START NEQ O THEN END,NEXT <@ ADDRESS(BUFFER) FTI? 
BND <= ADDRESS (RUFFER); 


QUIT IF CHANNEL ALREADY RUNNING 
IF START NEG O THEN RETURN 


ELSF 
START <# ADDRESS( BUFFER); 

TEMP <= O}3 

GOTO RESTART 
PL 
END? 
INTERRUPTS 

BEGIN 


t 


2s 





Programmers should insert here device and 
machine dependent code to terminate the 

! device transfer 

TEMP <= START. TERMADDR;} 

START <= START,NEXT? 


RESTARTS 
IF START = 0 
THEN 
GO TO TEMP 
ELSE 


! Programmers should insert here device and 
$ machine devendent code to initiate the 
! device transfer, 

Pile 

IF TeMP = 0 

THEN RETURN 

ELSE GO TO TEMP 

FT 

END 


3, MULTIPLE PRIORITY INTERRUPT HANDLER 

This test program is desicned to process interructs from 
mmeceviceszein priority order, Upon receiving an interrupt, 
the processor will braneh to the apoeropriate device service 
Poutine, All interrupts from lower priority devices will be 
disabled, Device priority is equal to device number, device 
mumber 1 has lowest priority, device 4 has highest, After 
the device denendent service tne device ID is added to the 
executive queue for user seneduling ourposes, Tnis program 
heea not be reentrant, Each device service routine will be 
Simulated by the algorithm below, 


TeevCR SERVICE ROUTINE INTEGER OWN A;3 FOR I <= i TN 
ACO0:2}) DO A <= (A*899) MOD 123757 OD; 
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4. VIRTUAL MEMORY SPACE EXCHANGE 

This algorithm will involve a superviSory call handler 
mech Vile Provide the £unNctions “call” and “return”, The 
Supervisor is to implement protected procedure calls with 
parameters. "call" will select index into a table of address 
space descriptors maintained by the Supervisor. The "call" 


performs the*followings 


1. Save the caller’s state, 
2, Determine the callee’s address space, 


3. Set up the memory mapping and protection to ace 
cess the callee’s address space, 


Tne "return" function takes no parameters, It re- 


Stores the aeanvironment active pefore the orevious 
Gali. 


5. SCALE VECTOR DISPLAY 
moe Seal aGorilenm.se€ales a 1st of Graphic vectors about a 


given center, The vectors are represented as: 


Sunce. on 4 pits 
X Coordinate Pop ts 
iatensicy 4 bits 
vy coordinate 1 25 e Ss 


PROCEDURE SCALEADJUSTCREF DLIST,VALUE LEN, 
VALUE XCENTR, VALUE YCENTR, 
VALUE SCALE)= 
BEGIN 
{0 LEQ XCENTR, YCENTR LEQ 2047 
ISCALE IS THE ACTUAL SCALE FACTOR TIMES 128 
INTEGER LEN,XCENTR,YCENTR,SCALE,I,XTMP,YTMP? 
RECORD VECTORCINT4 FUNCT,INT 12 X, INT4 INTEN, 
ire i?) ? 
MeetOR DLIST it: LeEN) > 
FOR I <= { TO LEN DO 


Ee 





XTMP <= DLIST,XCIJ*SCALE; 
YTMP <@ DLIST.YCIJ] *SCALE; 
IF DLIST.FUNCT(I] NEQ QO 
THEN 
XTMP <= XTMPSXCENTR¥C128=SCALE) ; 
YTEMP <= YTEMPY+YCENTR*(L28°SCALE);3 
FI; 
DLIST.XCI] <= XTMP/128; 
Dero, rtrd <= YIMP/i28;3 
OD; 
RETURN 
END 


6. ARRAY MANIPULATION = LU DECOMPOSITION 
This alaqorithm factors a Square matrix into an upper and 


lower triangular matrix, 


LUDECOMP(REFERENCE A, VALUE N)= 
BEGIN 
REAL ARRAY A{i:N,1i:N]3 
REAL MULT? 
INTEGER DIAG, ROW, COL; 
FOR DIAG <=i, Ne! DO 
FOR ROW <= DIAG41,N DO 
ALROW, DIAG] <= MULT<= ACROW,DIAG] /ACDIAG,DIAG) 
FOR COL <= DIAG+i1,N DO 
ACPOW, COL) <=A (ROW,COLJ =MULT#A (DIAG, COL) 


7. TARGET TRACKING 
TAis algoritnm takes tne coordinates of an unknown 


Sepece and finds in a table sorted by x coordinate the 


erosest entry, 


PROCEDURE TARGET(REFERENCE TABLE, VALUE LEN, VALUE X 
VALUE ¥, REFERENCE FOUND)= 
BEGIN 


mteGER LEN,START,END,#ID,UP,DOWN; 
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REAL MINDIST; 
ADDRESS FOUND 
RECORD TENTRYCREAL X, REAL Y¥, REAL DAT1,REAL DAT2);3 
TENTRY TABLE(C13LEN) 
START <= 13; END <= LEN; 
WHILE START <= END DO 
MID <= (START#END)/2 
IF TABLE.X(MID] < X 


THEN 
START <= MID+1 
ELSE 
END <= MID 
FT 
OD: 


!Compute distance of nearest x entry 
MINDIST <= DISTC(TABLECMID) ,X,_)3 
FOUND <» ADDRESS(TABLE(MID] ); 
'search neighborhood for a nearer entry 
UP <= MID4+13; DOWN <= MID#=13 
WHILE UP>0O OR DOWN >0 DO 
IF UP>O THEN CHECK(UP); UP<= UP +1 FI? 
IF DOWN >0O THEN CHECK(DOWN) 3 DOWN<=DOWN=1 FTI; 
DD? 
RETURN; 
'Cneck an individual entry aaainst closest found 
PROCEDURE#MACRO CHECK(J) = 
BEGIN 
IF J<i OR JOLEN OR ABS(TABLE.X(U] =X) >= MINDIST 
THEN J <#0 $ RETURN FI; 
DPeeDISTCTABLE[JU] ,X,¥) < MINDIST 
THEN 
MINDIST <= DISTC(TABLE(J] ,X,Y)3 
FOUND <= ADDRESSC(TABLE(J) ) 
PI; 
RETURN 
END 
! DIST() is the metric defined in the poroblen 
END 


Se DIGITAL COMMUNICATIONS PROCESSING 

This algoritnm is given a message with a header which 
contains the destination and connection ID, and places the 
message in the appropriate transmission line’s Sut ant 


ouffer, 


ee 





PROCEDURE FORWARDCREFERENCE MSG) = 

REGIN 

RECORD MESSAGECINT16 CID,INT1& DEST, INT16 SIZE 
CHARACTER MSG[13?])3 

BUFTABLECINTEGER CID,ADORESS BUFFER); 

MESSAGE MSG? 

POINTER BUFTABLE LINE? 

EXTERNAL ANDRESS DESTABLE(1:?7];3 

'Find BUFFER table for destination line 

LINE <= DESTABLE({MSG,DEST):; 

PEinad ring butfer for this connection 

pow<e 13 

WRILE LINE,CID{I]) NEQ MSG,CID 

DG @<= [| + 1 ODs 

BUFFER <# LINE ,BUFFER(I]); 

{Copy the message to the buffer 

MOVE(CADDRESS(MSG),BUFFER,MSG,SIZE);3 

RETURN 

END 


9. HASH TABLE SEARCH 
This program locates the position a Key would occupy in 
a hash table, 


PROCEDURE HASHLOOK(REFERENCE TABLE, VALUE SIZE, 
VEG, Soe oRkRENCE SOSTTION, 
REFERENCE FULL) = 
BEGIN 
ADDRESS POSITION 
PNT SSeR SIZSRPKEY,CHECK; 
BOOLEAN FULL} 
RECORD TENTRYCINTEGER KEY, INTEGER DATA); 
Meier’: TABLECOSSIZE=1); 
"Gomeute first place to look 
CHECK <= KEY MOD SIZE} 
FULL <= FALSE? 
FOR I <= 1 TO SIZE/2 ODO 
IF TARLE,KEY[CHECK] = KEY OR TABLE. KEY(CHECK] = 0 
THEN 
POSITION <= ADDRESSC(CTASLE. KEY [CHECK] )3 
RETURN 
fel 3 
CHECK <= (CHECK + I) MOD SIZE 
Od 
FULL <= TRUE 
RETURN 
END 
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10. LINKED LIST INSERTION 
Tnis algorithm inserts a node in an ordered doubly 


ioeed list, 


PROCEDURE LISTINSERTC(VALUE LISTCB, VALUE NEWENTRY)= 
BEGIN 
RECORD LCBCADDRESS HEAD, ADDRESS TAIL, 
INTEGER NUMENTRIES)3 
RECORD LISTENTRYCINT32 KEY,ADDRESS NEXT,ADDRESS PREV) 
SGrNwgeR LER LCISTCS; 
Pee eR LPSTENTRY, NEWENTRY,PRESENT; 
IF LISTCB,NUMENTRIES = 0 
THEN 
LISTCB,HEAD <@ LISTCE,TAIL <= NEWENTRY; 
LISTCB,NUMENTRIES <e 17 
NEWENTRY.NEXT <@ NEWENTRY.PREV <e 0 
ELSE 
PRESENT <e LISTCB.HEAD? 
LISTCB,NUMENTRIES <e LISTCB.NUMENTRIES+1; 
mone NEWENTRYsKEY GEQ PRESENT.KEY AND 
PRESENT,NEAT NEQ 0 
DO PRESENT <= PRESENT,.NEXT OD; 
IF PRESENT, PREV =0 AND NEWENTRY.KEY < PRESENT,KEY 
ae 
LISTCB.HEAD <@ NEWENTRY; 
NEWENTRY,PREV <= 03 
PRESENT.PREV <= NEWENTRY 
NEWENTRY NEXT <= PRESENT; 
TBS) 3 
Peete wENTRY,REY GEQ PRESENT.KEY 
ace N 
ERPOENT NEAT <= LISTCS, TAIL <= NEWENTRY?} 
NEWENTRY.NEAT <= QO; 
aera’ een ny <= PRESENT 
ELSE 
NEWENTRY,NEXT <*@ PRESENT? 
NEWENTRY,PREV <e@ PRESENT, PREV; 
BeeoGe NT «PREY <= NEWENTRY ; 
PRESENT <= NEWENTRY,.PREV; 
PRE GeNT, NEXT <* NEWENTRY 


2 


11. PRESORT ON A LARGE ADDRESS SPACE 


This algorithm takes an array of records iin 


random 


order and réarranges them to form a heap, The heap is a 


binary tree in which each node {1s greater than or 


its descendents, 


KEAPIFY(REFERENCE REC,VALUE N)= 
BEGIN 
INTEGER ARRAY RECLL:N])} 
INTEGER CHECK, NEW; 
FOR NEW <= 2, N DO 
CHECK <= NEW; 
WHILE CHECK NEQ 4 AND REC(CHECK] > REC(CHECK/ 
DO 
REC(CHECK] <=> REC(CHECK/2); 
CHECK <= CHECK/2 
OD 
OD 
END 


12. AUTOCORRELATE ON A LARGE ADDRESS SPACE 
TAis algorithm computes the autocorrelation 


mector A from i to T, 


PROCENURE AUTOCREFERENCE A, VALUE N,VALUE T, 
REFERENCE RES)= 
BEGIN 
INTEGER N,T,TAU? 
ereeaw ALLIEN], RES(1:T); 
See to<= 1 TO T DO RES{I] <= 0 OD: 
FOR I <= { TO N DO 
FOR TAU <= 1 TO T DO 
IF I + TAUt1 > N THEN EXITLOOP FI? 
RESCTAU) <= RESCTAU) + ACI] *A(CI+TAU-1);3 
OD 
OD 
RETURN 
END 


a5 0 


equal 


2] 


of 


to 
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13. CHARACTER SEARCH 
This algorithm searches & given string to see if it 
contains a substring that exactly matches the given argument 


Sr LNG « 


PROCEDURE CHARSRCHC(REF SRCHSTR, VALUE SRCHLNGTH, 
REF SRCHARG, VALU ARGLNGTH,REF LOC)= 
BEGIN 
INTEGER 1,SRCHLNGTH, ARGLNGTH;} 
BYTEVECTOR SRCHSTR(O:3SRCHLNGTH#=1)],SRCHARG(OSARGLNGTH#=1] 
LOC <= #1; 
IF ARGLNGTH LEQ O THEN LOC <= Of RETURN FI; 
FOR I IN 0,SRCHLNGTH*ARGLNGTH DO 
IF SRCHSTR(CIST+ARGLNGTH] LEQ SRCHARG 

tae oOoe <= Le RETURN FTI; 
ODs 
RETURN 
END 


14. BOOLEAN MATRIX TRANSPOSE 
TALs algorithm computes the transpose of a qiven N by N 


Macrix in place, 


PROCEDURE BMTC(VAL N,VAL Al, VAL A2) = 
BEGIN 
INTEGER I,J? 
BOOLEAN B(1:N,12N] 
FOR IT IN 1,Ne1 7 J IN I+#1,N DO 
BCI,J] <=> BCJ,T) 


15. RECORD UNPACKING 
This algorithm unpacks the fields of a record into an 


integer array, 


PROCEDURE UNPACK(REF RECORD, REF FORMAT, VALUE LEN 
REF RESULT)= 
BEGIN 
BITSTRING RECORD{[0:?]? 
INTEGER LEN,START,RESULT(13LEN),TEMP,I; 
ARBTYPE FORMAT(LSLEN]3 
START <= 0 
FOR I <= 1 TO LEN 0C 
TEMP <= PECORD(ISTARTISTART+FORMAT(I] <1]; 
START ,2 START + FORMAT(T); 
IF FORMAT(I] IS A DISTINGUISHED VALUE 


hae N 
TEMP <= SIGNNEXTENDC(CTEMP) 
er. 
RESULT(CI] <= TEMP; 
OD; 
RETURN 
END 


16. VECTOR TO SCAN LINE CONVERSION 
Perey algqerithm takes. a list of vectors and produces a 


raster scan line conversion, 


BeOeepURE YVECECANCREF DLIST,VALUE LEN, REF TEMP)= 

BEGIN 

PeORD DESPLAYCINT165 XS, INTIE YS, INT16 XE, INTi6 YE), 
WOnCenott lao Xo,iNl16 XE, INT32 Y,IPNT32 SLOPE); 

DISPLAY DOLIST(i:LeEN] 

WORKLIST TEMPCISLENY1) 3 

Meare Lf, oLART, LINE, DENOM; 

BeerolRtNG BIT(1:1924); 


!Generate working vector 
pees t <= 1 TO LEN DO 
Teme XSL) <= OLIST.XS(I); 
TEMP. XE <= PLIST.XECI): 
foeee rt tl) <= DEIST. YS (13) #1024; 
CEM Se (DUIST.AE{T) = DLIST.XS(CI) + 1)? 
Pe4eeouuUrPE tis <= (€DLUIST YECITJ=DLIST.YS(1I])*1024/DENOM 


are 





OD; 


TEMP XSC{CLEN4#1] <= 1025 

! Generate the scan image 

START <= 13 

FOR LINE <= { TO 1024 DG 
BIT <= 0 


i 


<= START} 


WHILE TEMP.XS(I) LEQ LINE DO 


Bate Geto. . CLI 7A024 TO (TEMP, YCII. + 
TEMP,SLOPECIIJ)/19024 
Combet en, <= 1 0D; 
TEMP,YCI) <= TEMP,Y(I)] + TEMP,SLOPE(I]; 
IF TEMP,XECT) = LINE 
THEN TEMPCSTART] <=> TEMP(T]; 
Stee te<= STAaT + 1; 
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Recon D LA & 


CDS 432/670 USERS MANUAL 


The following is an effort to enable Someone with no 
prior Knowledge of the 432/600 system to be able to compile, 
link, and execute programs on the 432 in a minimum amount of 
time and ‘’fuss’, A Knowledge of ADA 18 assumed, as 15 
familiarity with VMS (e.g, the VMS editor), 

Referring back to Figuref{6) it can be seen that a 
variety of hardware and software is tnvolved in simply 
Weeeing @ program to “run® on the 432, This variety of 
needed hardware/software f{s collectively referred to as tne 
wee Gross Development System", or "CDOS" for short. Not 
Sererisingly, those functions né@eded first in order to 
achieve the desired result of a program executing on the 432 
are accomplished on the VAX 11/780 nost. Briefly, the steps 


recuired,plus their CDS ’companion @lements’ are: 


1, Program Creation/Editing == VAX/VMS 


we Comat lation ee VAX/VMS 
Sa winking om VAX/SVUS 
4. Downloading ee MDS 890 


S. Program Load/Execution “== MDS 800/432 





1. PROGRAM CREATION/EDITING 

Creation of a login fille with at least the following 
commands will substantially add to the eaSe of your terminal 
sessions while workina with those CDS parts which reside = on 


the VAX/VMS hosts: 


SADA432 
Smopo 3== del ¥*,mso; ¥+*,mbo;* 
Smooce s==s del *.msc;*+*,mbc; * 


Smope :== de] ¥*,mse;*+*, mbe; * 


The reason for these commands will become evident as we 
egimc. ne. 
ADA source files to be compiled by the Intel ADA cross 
compiler must nave a file extension type of either: 
1. <fllename>.MSS => An ADA Source specification 
file. 
2e <filename>.MBS => An ADA source body file, 


3. <filename>,MCS => Both specification and pody. 


In our opinion, dividing source code into separate 
specification (.“SS) and body (.M8S) files was in Keeping 
Beemer, Gome of the original ophilesopnies behind ADA, 1.6é., 
Sncepsulation <@nd information NAilding. Unfortunately, the 
compllation efforts, of necessity, must double (2 files to 
compile vs, i in the MCS cas@). What follows next are 


figures of a sample orogram, Figure 19 illustrates the 


SS 





SBavesion into specification and body, Figure 20 illustrates 
the combined (MCS) format. Besides the distinction of 
working with two separate files as opposed to one, take 
special note of the line, common to tne ’bdody’, which begins 


with "pragma environmentrere 


a re. ea ae a aa a ae ar se 
J samen ranvnnanasaaaaeon | 


[| package EXAMPLE! {s | 
} procedure SIMPLE; | 
1 end EXAMPLE!I? | 


a 


| Tne specification filed as EXAMPLE1.MSS 


| The body filed as EXAMPLE1.MBS | 
V V 


pragma environment C"ACS:TEXTIO,MLE", "EXAMPLE1,MSE", 
Weve LOeM Se) 5 

Steen eeexee io, intio: 

Wiese" CAREC LO,29tio,ascili; 

Dackage body EXAMPLE! {fs 

procedure SIMPLE is 


MeeVee * ineeager; 


y $= 15) 
Bice imesioC" SIMPLE ee 
putcbel); 
“= tnis rings the bell,’use ascii’enables this 
Zt = x4 ys 
Dumez,; = “Imntio"= allows you to do this 
DUtGoe)) >; 
Seo lLin@erOC"END SIMPLE") > 
end SIMPLE? 
end EXAMPLE? 


- 1-4) ah - —  a  e  e R E  R @  e SG 


Fiqure 19, Specification and Body Format (Sevarate) 
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ee ee em me ee ee 
praama environment ("ACSSTEXTIO.MLE", "INTIO.MSE")3 
ween textc lo, int1o?; 
use textiio,intlo; 
opackaae EXAMPLE2 is 
procedure SIMPLE; 
end EXAMPLE2; 


backage body EXAMPLE2 {s 
erocedure SIMPLE is 


K,¥,z2 : integer; 


“wow o 


Begi 
¥ is 410? 
yY & Lo} 
Putaclinesi0(" SIMPLE i) 
put (bel); 
Zs x+y? 

PUut(Z); 

Dutewlinesl1OC"END SIMPLE"); 
end SIMPLE? 


end EXAMPLE2; 


Combined specification and body filed as 


el lh alle Fit ll RE ll Allie a aD a TE. a Tithe lll — hl Gl ag — la ll an DG he ig 


Fiqure 20, A Combined Format Examole 


Information is conveyed to the ADA comoiler system by 
means of oragmas, The environment oraqma soecifies the names 
of external environment files (Cor library units) that 
Gomscitute the compilation environment for the current 
compilation unit(s). If the current comoflaticn depends on 
Sewer compllation units from other compilations, then the 
environment files from these compllations must be listed in 


the ENVIRONMENT pragma in the current compilation, These 


Se) 





environment pragmas enable s@parate Compilation while still 
maintaining strong type checking of interfaces, two features 
which ADA is supposed to fulfill. In these examples the 
compilation of the body depends ons 
S"SAcogtevlLogiue =|» SO Che package “can perform 
enaracte@r 1/0, 


e- INTIO,MSE => s0 th@ oackaqe can perform integer 
r7 ©. 


ewe EXAMPLEL.MSE => the corresponding specification 

Elle, 

To alleviate confusion on file extensions, the following 
foeeea List of VMS file ‘@xtensgions used in the 432 ADA 


Compiler System (ACS), 


ie First character: 


M e= Tne fille contains a liprary unit. M stands 
for mocule, 


S ==saTtTh@wtlle contains wa’ SEPARATE stub, 
Zar second Character: 


S #«= Tne file contains a Program unit specifica= 
tion. 


B == The fille contains a program unit body. 

C == Tne file contains the combination of a vdroe= 
Gram unit speeiticgaction and a procram unit 
body. 


L «= Tne flle is a program liprary file supplied 
bY =Llrtel’. 


Beet o Clast) Character: 


S «= The file is an ADA source text file, 





E = The file is an environment file, 

R == The file is a REPORT file. 

O == Tne file is an object code (EOD) file, 

L == The file is a REPORT listing file. 

C e= The file is an object code listing file, 

wae the fire 1S a specification fille fer the 
COMBINE utility and contains a list of en= 


vironment files that are to pe meraed, 


I w= Tne file is an intecrated environment file 
created by the COMBINE utility. 


T -= Tne file is a listing f£ile produced by COM-= 


BINE and contains the file table listing of 
the intecrated environment, 


more aaaed clarification: 
e.g. <filename>,MSS == An ADA Source text file 


wen COtMMSsSpenas to a specification, 


e.g. <filename>,“BS == An ADA Source file contain= 
ing program unit bodies, 


e.g, TEXTIO.MLE == A library environment file sup= 
bli@a by Intel. 


2. COMPILATION o 

The Intel compiler is invoked by the command 
mepaA', followed ody the filename, If the filename is 
morected, tne comoiler will promot for it, Our input to the 
Compiler consisted either o£ <filename,.MSS>, for 
eeecification files, or <filename,MBS>, for the 
moprementation, 1.@., body, filles, Output from a successful 


@omopilation consists of files of type: 
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1. eMBE or .MSE == The environment file represene= 
Gaicion, 


2. eMBC or .MSC == The object code listing file. 
It is utilized when debuaging on the 432, 


3. eMBO or ,MSO == The object code, This is input 
to the linking orocess, 


Unsuccessful compilation results in £lles of the type: 


Pee es OS eMou “== <A resort listing fille. We qen- 
erally never used this. 


2. eMBR or .MSR == A file which when prefixed by 
the command "REPORT", e.g., REPORT prog,mbr, al-= 
lows one to scan thro'gnh one’s orogram on the 
terminal, More importantly, all errors detected 
by the eonoller are flagged ine cdg their 
eeorresponding diagnostic message, 


A tyoical session on VAX/VMS consists of the following: 


Pe eaode Sma compile tne specification fille for the 
Beoolem, {.@., tne program, at Nand. Since a 
specification file is essentially just a means of 
formalizing in ADA what one considers the inter= 
face to he, it usually needs no environment orag-= 
ma statement, 


Peemeocm and compile th® body, which is the means pby 
wnich one implements the program, Since the body 
depends on what the interface is, tne environment 
file representation of the corresponding soecifi- 
cation file must be included, Beaitionalives, L£ 
i7 Os tComee performed im the body, whieh fs qen- 
erally the case, the general I/0, Intelesupolied 
Paermac@™ (TEXTIO}, must, aiso be included in the 
pragma environment statement, 


An example of all this can be found in Apoendix C, which 
Shows the ADA source code for the programs done in tnis 


emesis, 
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In case it wasn’t made clear in the above discussions, 
compilation order is important. Any modules included in the 
pragma environment statement or referenced in the standard 
meee Comecructs, "WITH..." and "USE..." must be sucee@ssfully 
compiled beforehand, otherwise unsuccessful comoilation is 
all the reward one will get for one’s efforts in the current 
compilation attempt. 

Successful comoilation means the creation of three new 
eiewes in *eddition to the original source file, Directory 
space in VMS is quickly exhausted if one is Performing many 
Gemorlations, Without adequate directory space, the INTEL 
compiler and linker will abort. Therefore, wnen asking for 
an account, the system managers must be informed that more 
directory space than Js normally aqiven a VMS user is needed, 
Furthermore, in an attempt to orevide a quick means of 
deleting unneeded envirenment, object=code listing, and 
object=code files, the commands, mone, mope, and mopo will 
automatically delete all files of the corresSnonding filetyne 
oe ne Current directory. 

Once one Nas successfully defined one’s interface, coded 
he, comoiled Lt, and has done the same with the 
corresponding body or bodies, one has reached the point 
where in most traditional systems one is ready to link the 
object code in preparation for actual program execution. In 
pee 432 case®, additional compilation must still be performed 


before the linking process mav begin, 
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First, a module termed PSERP.MBS must be compiled. An 
example of this is included in Appendix C, Its function Its 
to initialize the user process(es). It essentially marks 
maven moedule is to begin .execution first. For instance, a 
Driver routine which invokes all other subroutines is 
usually executed ole Sige In Our cas@®, PSERP always 
initialized the Driver routine, which we always termed MAIN, 
meee attempt to cut down on our coding/compllation eétorts. 

Secondly, as vcointed out in the arenitecture overview on 
operating system support, users can tailor some of tne iMAX 
0.S. packages, In this thesis, modification of the system 
configuration package, PSORS.MBS,was implemented. Hence, the 
successful compilation of this modified package was also 


meedecd. This package is also included in Appendix C, 


3. LINKING 

Tae .“SO or .MBO f11@8S produced by a successful 
Sempitation are input to thé 432 linker by being listed in a 
user created directives file, The outout from a successful 
Merk is of filetype .FOD, EQD stands for "Externel Object 
Description", Actually, the resoective MSO and ¥BO output 
faeess from the compiler are in this EOD format, The choice 
Meo ing EOD @s the. ftiletyoe of the outout from the linker 
mseeemn arbitrary one. 

The 432 linker combines a set of compiled EOQD’S (e.95, 


the .MSO and .480 files) into a single linked END, Compiled 
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EQD’s, generated by tne ACS, contain program modules. These 
modules, in turn, contain a collection of comoller-cenerated 
objects, such as seaqments, refinements, ete. The output from 
the linking process, a single fille, is then downloaded to 
the MDS 800 system, 

The 432 linker performs the following traditional 


eunettiens’s 


1. Resolves inter=module references, 


2 Assians physical memory addresses to all segments 
contained in the input modules, 


3. Verifies the compatibility of modules that are 
linked together. 


4, Produces a linked EOD that may be loaded into tne 
System 432/670 main memory and executed, 


5S, Generates error messages fer abnormal conditions 
encountered during processing, 


6. Generates a linker listina that Summarizes the 
results of the linker operation and address as= 
stanment, 


In addition, the linker performs the following 432especific 


aecions: 


1. Version cnecks the input ECQDS for compatinility, 


2. Assigns oodtect table directory indices and onject 
table indices CKnown as object coordinates) for 
objects contained within the input nodules, 


3, Builds the ptvsical 432 access seqments deseribed 
symbolically within each input module, 


4. Bullds object tables and the object table direc= 


tory associated with the objects in tne indut 
modules, 
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5. Generates initialization object tables, access 
descriptors, and storage allocation information, 
The net result of all this is an EOD which, when loaded 
into 432 memory, will execute as one has programmed it, 
The input or directives fille to the 432 linker should be 
a file created on VMS with a file extension of LKD, This 
file, an example of which is provided in Figure 21, may have 
other file extensions or types. However, if tnat {is the 
caSe, then the full £fLle name must be given to the linker, 
i1.e., LKD is the default file tyne. For example, given a 
Banker ane ween we Call “TEST.UKD", to link this file, the 


followina command would be entered: 


LINK432 TEST 


The linking process can be appreciably longer than 
cOmpilation., However, if linkage is successful, @ single, 


simple message of: 


LINKAGE SUCCESSFUL 


should be the only message which appears on the console, 
Warning messaqes, not error messages, accompanied py 
"LINKAGE SUCCESSFUL", do not really mean ae successful 
linkage! At least this has heen true in our experlence, A 
detailed explanation of the different directives whiecn can 
appear itn the linker file, plus their meaninas, can be found 


in tne manual, "VAX/VMYS Host User’s Guide", With the 


144 





Sulminaeecion Of © at’ Suce@ssful linking, oné fs ready to 
download the output fille generated by the linker to the MDS 
800 system, For a detailed explanation of the linking 
process and the available directives,i1.@., commands included 


in the link file, refer to "VAX/VMS Host User’s Guide", 


3; An example of a link file which serves as input 

s to tne 432 linker, The semicolons whiecn precede 

;Tnese statements signify comments, Link,free, 
outout,orint, and objectmap are examples of 
linker directives. Tne blank lines which occur 
between directives MUST be present! 


=e eo Ye 


link ACS!:iLMAXV1i.eod 
BES? Vextio.,mis 
examplei.,mso 
examplel.,™7bo 
main,mso 

main.™bpo 

oserp,mbo 

osors,mbo 


freeti in directory) 
output example,eod 


print example,.mao 
objectmap 


Tnis could be filed in VMS as TEST,LKD 


il lll — A — lp — AT TI i — A lh i, — il le aah ac Bg a Ra oa Sg OE 


Filaure 21, A Linker Input File 


4. DOWNLOADING 
Downloading {s performed on the MDS 800 system, Gel 


order for downloading to be accomplisned, the VAX must be 





operating under VMS, A cable, marked with a tag which reads 
"VAX", is the transmission facility for downloading. The 
following steps comprise the procedure to follow when 


downloading a files 


1. Attach the VAX cable to the ADM36 terminal, Logon 
to VMS as you normally would. Enter the following 
command : "SET TERM/SPEFOD=2400", This is done be= 
cause the MDS 800 svstem is currently modified to 
supoort only 2400 baud communication rates unless 
hardware/software cnanaes are implemented, 


2. Remove the VAX cable from the ADM terminal, cons 
nect one end to a null modem, Connect the other 
ana of thé null mo@em to the MDS 800"TTY vort lo=- 
Camec On the €ontrol Unit. 


3. Insert into drive 0 of the ADS 800 system the 
ASYNCH LINK diskette, 


woetmeere imtoearive { the disketté= one wishés to 
download to, Root the system, 


5. On the MDS 800 terminal, enter the following come 
mand : "DNLOAD <VMS EOD filie> TO t:Fi:<new or same 
file name>, For instance, assume one nas an EDD 
Rete named TEST,EOD in the VMS directory. Furths 
ermore, one wishes to call this file TEST1,.£0D on 
the MDS 809 system, One would enter tha following 
command: "PNLOAD gu Dow Ay BEB) Lo 
weet eort,fOD", quetes not iIneluded, 

N@ Wave experienced average download times et 
approximately 20 minutes. Any errors in transmission mean 
that downloading must be redone until a complete errorefree 
Gownload is accomplished, we have not experienced any errors 
Meeeownboa@daina to date. The concluston of a successful 


download marks the beginning of the next step, execution on 


the 432, 
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Se PROGRAM LOAD/EXECUTION 

Now that a linked EQD file is on a diskette, all that 
remains tis to load it into 432 memory and execute it. The 
following procedure assumes that the MDS 800 system and the 
432/670 execution vehicle are powered up and have no 
nardware faults. In the following discussion, commands which 
are to be entered at the MOS 800 terminal (termed the 
"debugger console" by INTEL) will be printed in capital 
letters and enclosed in quotes. This fs for illustration 
purposes only, Capital letters are not necesSary, and quotes 
Will result in an error message. 

iepinsere into, drive oO of the MDS 9800 “Systen, the 

diskette labeled UPDATE+#432/DE8UG=432, 


Poemineere ineoedarive } the diskette which contains 
the executable procram, Boot the system, 


3. Enter the following command: "RUN WORK :FOs", 


4. When the ISIS promot (=) returns, enters: "RUN 
Deessz2". Ins Should resuit in the display of 
"SERIES III 432 Systems Level Debugger, v1.00", 


Smce in thée™debucaer” tie, ISIS orompt will »b?@ 
replaced by a "?" as the prompt symbol. Enter the 
Command: "INIT", 


6. When the prompt returns, enters MENCEUDE 
DEB432,TEM", 


faannemetheé PrOmot r®tGurns, enters: "DEBUG eo We 4 
fillename,filletype o>", For examole, suppose one 
has downloaded the flle TEST.EOQD wniechn one wisnes 
to execute, Here, one would enters "~BEBUG 
Telel es. B00", 


Seeoweer. "SlSRT™,. This command initiates program 
execution, 
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This command will result in program execution on the 
432, For an titinedeptnh explanation of debugging facilities 
available on the 432, in ease the program does not execute 


as planned, refer to "Workstation User’s Guide", 
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